[chuck-users] Expanding MIDI support

[Jack Atherton]

According to the headers, ChucK uses RtMidi Version 1.0.4 from 14 October
2005.

On Fri, Jul 5, 2019 at 10:10 AM Forrest Cahoon <forrest.cahoon at gmail.com>
wrote:

> Have you grabbed the latest rtmidi sources from
> https://github.com/thestk/rtmidi ?
>
> I briefly looked for the code you reported changing and didn't see
> anything that looked like that in HEAD.
>
> On Wed, Jul 3, 2019 at 3:22 PM mario buoninfante <
> mario.buoninfante at gmail.com> wrote:
>
>> I've found a workaround (not sure it's a proper one though!)
>>
>> more info here: https://github.com/ccrma/chuck/issues/130
>>
>> this now allows to send SysEx from Linux as well :)
>> On 02/07/2019 22:15, Michael Heuer wrote:
>>
>> Great, thanks!  I'll start a new thread asking how best to use it!
>>
>>    michael
>>
>>
>> On Jul 2, 2019, at 3:53 PM, Mario Buoninfante <
>> mario.buoninfante at gmail.com> wrote:
>>
>> Nice :)
>> MIDI clock works fine now (ChucK 1.4.0.0). There's a flag you can use to
>> activate it that I don't remember whether is ON or OFF by default, but
>> anyway is there.
>> Like I said there's a flag for SysEx as well, but that doesn't seem to do
>> much.
>>
>> Cheers,
>> Mario
>>
>> On Tue, 2 Jul 2019 at 21:43, Michael Heuer <heuermh at gmail.com> wrote:
>>
>>> I'd say go for it!  It would be nice to have proper SysEx and MIDI clock
>>> support in ChucK.
>>>
>>> I recall there was some progress on the latter; did I read somewhere
>>> that clock messages are available via RtMidi but simply disabled in ChucK
>>> for performance reasons?
>>>
>>>    michael
>>>
>>>
>>> > On Jul 2, 2019, at 3:23 PM, Mario Buoninfante <
>>> mario.buoninfante at gmail.com> wrote:
>>> >
>>> > Hi everybody,
>>> >
>>> > One month ago I got started with an Open Source project whose goal is
>>> to support some hardware on various platforms/environments/programming
>>> languages (Pd, SC, Processing, Lua, Python, JS, etc.) and of course my goal
>>> is to have ChucK on board as well (hopefully I'll share more info about the
>>> project in the next months).
>>> > The only issue I've got at the moment is that I need to talk SysEx
>>> with these gears, and as you know ChucK doesn't deal with SysEx.
>>> > I really care a lot about this project, mainly because it's open
>>> source and because will involve different communities (Pd, SC, JS, etc.)
>>> and would really love to include ChucK in this since is the tool I'm mainly
>>> using to experiment and make music and I truly believe has got something
>>> more than other languages/environments.
>>> > Thus, since I'm not a C++ person, I decided I'll ask a colleague of
>>> mine (a C++ programmer) to help out with this, also because he'll get
>>> involved in the project for other reasons anyway.
>>> > But before doing this I wanted to ask the developers and all those who
>>> are involved in maintaining ChucK, if there's any particular reason why
>>> SysEx messages are not currently supported.
>>> > From what I can see in the code (and after running few experiments)
>>> with the current architecture SysEx messages could be sent out (3 bytes at
>>> time though) but with a lot of limitations (didn't manage to receive SysEx
>>> messages though).
>>> > Also, I think RtMidi doesn't gate us from doing that (there's just a
>>> flag used to 'turn on/off' SysEx communication).
>>> > But it seems like there's nothing in place that allows to deal with
>>> MIDI messages bigger than 3 bytes and, from a "non-C++ person", it seems
>>> one way to fix this could potentially be to add a SysExIn/SysExOut and a
>>> SysExMsg classes that deal with these kind of MIDI messages.
>>> > Of course there could be a lot of things I'm missing here, and that's
>>> why I'm asking you for some help, even before asking for other help :)
>>> > Just to make sure there's nothing that prevents people from adding
>>> this functionality.
>>> > Then, last but not the least, ChucK is an open source project and I
>>> love it. There are a lot of people working with it, and I was wondering
>>> whether or not this would be a feature people are after.
>>> > Basically I'd like to hear from the community before even getting
>>> started with this.
>>> >
>>> > I hope this makes sense. Looking forward to hearing from you guys :)
>>> >
>>> > Cheers,
>>> > Mario
>>> > _______________________________________________
>>> > chuck-users mailing list
>>> > chuck-users at lists.cs.princeton.edu
>>> > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>> _______________________________________________
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
>>
>>
>> _______________________________________________
>> chuck-users mailing listchuck-users at lists.cs.princeton.eduhttps://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
>> --
>> Electronic Musician, Creative Coder, QA Engineerhttps://vimeo.com/creativecodingsalernohttp://mbuoninfante.tumblr.com/https://github.com/mariobuoninfantehttps://bitbucket.org/mariobuoninfante/
>>
>> _______________________________________________
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20190705/f7159f6e/attachment-0001.html>