Hi all, Is it possible to send arbitrary midi messages like F0 00 01 61 03 04 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F F7 (for example) ? I understand that you can work with hex, but it seems that MidiMsg is fixed at 3 data slots, and MidiIn and MidiOut interface via MidiMsg. Is there any way to use MidiOut without MidiMsg? Or possibly overload the class with a more flexible message holder? Cheers, Julian
On 7 August 2012 17:39, Julian Faust
Hi all,
Hey Julian.
Is it possible to send arbitrary midi messages like F0 00 01 61 03 04 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F F7 (for example) ? I understand that you can work with hex, but it seems that MidiMsg is fixed at 3 data slots, and MidiIn and MidiOut interface via MidiMsg. Is there any way to use MidiOut without MidiMsg? Or possibly overload the class with a more flexible message holder?
Maybe :-). our MIDI works with the mentioned 3 byte messages, but in the past I managed to "cheat" it and reliably send 2 byte messages (patch and bank changes). I think I left the 3rd byte blank or maybe I set it to zero (might be the same thing). Anyway, by chopping up your message into 3 byte blocks and sending those in order you might be able to get it through, I have high hopes for that. I'd appreciate it if you'd report back any findings. Yours, Kas.
Instant addendum; This is only for getting data out of ChucK, not back in, because at receiving MIDI messages of lengths other than 3 will be discarded in the implementation. That won't change without hacking up the C++ source, but to make use of such messages you'd also need to add stuff to the ChucK language to actually make use of the data. This means bad news if your device wants some sort of handshake to deal with your message, I think some of those MPC-inspired controllers do. I thought I'd warn before you waste your time, I know how time-consuming this kind of thing can be. Kas.
On 2012-08-07 18:53, Kassen wrote:
That won't change without hacking up the C++ source,
I did the attached patch some time back... -- Atte http://atte.dk http://modlys.dk
Atte;
I did the attached patch some time back...
:-D IMHO we increasingly need a repository for user-contributed branches and some sort of process for testing them and perhaps moving them to the main distribution. I imagine that patches like this could be added in the form of branches and tested by those willing to risk a crash or two. Once a patch would turn out to be useful, stable and coherent with the rest according to some group of users somebody like Ge or Spencer could review it and perhaps move it in. That way there is less risk of crashing stuff making it in and we minimise putting extra pressure on the dev-time of the devs, while still making use of the resources that we have as a community. IMHO we currently could use this kind of contribution and we have the capacity to generate them, but no real way of joining those. That's a waste, I feel. I know that particularly Spencer sees benefits in a centralised process (and I agree those are there!) but I think that with something like the above we could get a lot of the benefits of a distributed one yet still maintain centralised oversight. Yours, Kas.
On Tue, Aug 7, 2012 at 11:48 AM, Kassen
On 7 August 2012 17:39, Julian Faust
wrote: Hi all,
Hey Julian.
Is it possible to send arbitrary midi messages like F0 00 01 61 03 04 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F F7 (for example) ? I understand that you can work with hex, but it seems that MidiMsg is fixed at 3 data slots, and MidiIn and MidiOut interface via MidiMsg. Is there any way to use MidiOut without MidiMsg? Or possibly overload the class with a more flexible message holder?
Maybe :-). our MIDI works with the mentioned 3 byte messages, but in the past I managed to "cheat" it and reliably send 2 byte messages (patch and bank changes). I think I left the 3rd byte blank or maybe I set it to zero (might be the same thing). Anyway, by chopping up your message into 3 byte blocks and sending those in order you might be able to get it through, I have high hopes for that.
I'd appreciate it if you'd report back any findings.
Me too.
I typically use Processing + rwmidi to send MIDI to ChucK and have
been wanting to do the same within ChucK.
http://processing.org
https://github.com/heuermh/rwmidi
I started here but haven't got too far
https://github.com/heuermh/lick/blob/master/ControlChangeMidiMsg.ck
https://github.com/heuermh/lick/blob/master/NoteOffMidiMsg.ck
https://github.com/heuermh/lick/blob/master/NoteOnMidiMsg.ck
https://github.com/heuermh/lick/blob/master/MeeBlipMidi.ck
See also forwarded thread below.
michael
---------- Forwarded message ----------
From: Michael Heuer
Michael Heuer wrote:
Lucas Zawacki wrote:
I think this hidden gem was mentioned by Kassen somewhere and I've used it ever since to manipulate MIDI: http://www.rattus.net/~packrat/audio/ChucK/
Ah yes, thanks Lucas, just found this on the ChucK wiki. Is the author Bruce on the mailing list?
He used to be, at least, that's how I first heard about this, I think. People develop and intrests change; I'm not sure he still is on the list.
Maybe someone else can help explain this part to me then? I'm not good at bit-twidding. ((command & 0xf) << 4) | ((channel - 1) & 0xf) => midimessage.data1; command | channel => command; byte1 & 0x7f => midimessage.data2; byte2 & 0x7f => midimessage.data3; midiport.send(midimessage); Why is the ... => command; line there? Isn't that dead code? The bitwise and value for data2 and data3 (0x7f) is not the same I see in this java midi library (0xff) https://github.com/heuermh/rwmidi/blob/2d73ac726f5000c85dd7aa3eb160872acb60a... Thanks, michael
participants (4)
-
Atte André Jensen
-
Julian Faust
-
Kassen
-
Michael Heuer