Combining two Midi events into one (Ruby midi)

[kortezzzz]

I'm still looking for a decent solution for combining midi notes events with pitch-band in ruby. Eventually, The summed midi signal should be streamed from my FS exported .exe standalone application to a DAW (or any other outer midi input target) via virtual midi cable, so in this case, it would be impossible to use FS's pitch-band primitive, since its good for manipulating poly signals in synths and cannot send independent pitch manipulation command to other outer midi input targets. So far I had no success with it. Any solution caused crashes. But, here is a conceptual idea that I came to my mind and I need help with it: lets say that 2 different ruby modules generate 2 different signals: the first generates only notes and the second only reads the pitch-band that comes from the midi keyboard's pitchwheel. Their next "station" would be then a new ruby module with 2 midi inputs and a single output and it would combine them both to a single stream and would actually function as a kinda "midi mixer" (maybe by creating a new midi array based on both inputs? I have no idea...). Any chance it could be done?

[tulamide]

I probably just don't understand the real issue, because what I understood from your explanations doesn't make sense to me.

There are midi messages. Those are 2 or 3 byte blocks that are coded following the midi specifications. Anything that changes the specifications can't be send as midi. One specification is that each midi event has its own event block (for example note on, note off, balance, pan, or pitchbend).

One problem seems to be that Flowstone filters the bitchbend-event? I was already wondering why this prim exists, when you could just as well read it from the midi stream. If Flowstone completely filters it out from the midi stream (has someone tested?), then it is not so easy to work it back in because there's only the green integer for the pitchbend position, while the midi message also contains channel information and such. Also, because of green conversion, it would probably be delayed when put back to the midi-stream somehow.

Maybe something switchable via Flowstone's options, wether to receive midi as now implemented, or prohibiting the bitchbend-prim for getting an unfiltered midi stream?

Without help from Flowstone it will be an insecure implementation at least, trying to use just the green bending info.

[Nubeat7]

this was explained already here:
viewtopic.php?f=3&t=3294&p=17614#p17614

note messages and pitchbend messages are 2 different midimessages you cannot modify the notevalues (which are ints) with pitchbendmessages inside the "midi - world"
just send the pitchbend through when it comes from the outside, or feed it into the midi signalpath when its created inside the FS app...

[kortezzzz]

One problem seems to be that Flowstone filters the bitchbend-event? I was already wondering why this prim exists, when you could just as well read it from the midi stream. If Flowstone completely filters it out from the midi stream (has someone tested?), then it is not so easy to work it back in because there's only the green integer for the pitchbend position, while the midi message also contains channel information and such. Also, because of green conversion, it would probably be delayed when put back to the midi-stream somehow.

Yep, you nailed the problem. Whenever you use "midi event"+"midi split" combination and\or manipulating midi stream by using ruby (for instance, to virtually split the midi keyboard into high\low zones), it seems that the pitchband message is filtered out. That's really annoying since you can send out pure midi stream correctly to other midi-in target.
Moreover, you can't for instance add a pitch-wheel control knob into your project and make it work correctly since right now, it must be based on that "pitchband" primitive and only allow internal green integers manipulations on poly frequency and nothing else. Was hoping that ruby has a solution for that, but after following your post, I see it probably hasn't. The only way I could see is extracting the pitch-band messages from a separate "midi split" primitive and then adding it back into the general midi stream somehow (maybe by ruby?) just before the midi is sent out through. So far, no luck. Once you connect the pitchband data with the general midi stream (that contains the notes data), the whole thing just freaks out. That's why I've pondered the ruby midi mixer solution.

[kortezzzz]

just send the pitchbend through when it comes from the outside, or feed it into the midi signalpath when its created inside the FS app...

@Nubeat7,

Somehow missed your reply and mentioned it only now...

Already tried the methods you've suggested and they haven't worked for me. Not sure why. Maybe it's more related to the virtual midi cable limitations and not directly to FS itself. What I've actually did is isolating the pitch-band message (status=224) by using "midi split" and "midi event" and connecting it's midi output additionally, straight to the general breaking out midi output path (which contains the notes-channel-velocity data). Maybe it's something I'm doing wrong?