Filtering a specific midi channel from a packed midi event

[kortezzzz]

Bouncing in the modern digital DAW environment, in most cases refers to an instant translation of a midi track to an audio one, in place. Usually to save CPU whenever the user is already satisfied with the results and prefer continuing editing it in it's audio form.
The problem with FS's green midi then is that whenever you bounce a midi track, it fails translating it and you end up with chopped and untuned notes. Therefore, you should avoid passing your notes through any green midi process, or you end up with a corrupt bounce.

More about bouncing midi here, in this video.

https://www.youtube.com/watch?v=jPKIRqPtWxk

[Spogg]

Thank you so much for that!

If I actually made music with a DAW I would doubtless have realised the usage of the term “Bouncing” has changed. So it’s good to pick up on this type of information.

I guess the green MIDI processing is why I had to render my Bagpipe music (from a modified midi file) in real time. I got the effect you described when I tried to do it offline (fast), but I somehow thought it was a Reaper issue and didn’t pursue it because I got what I wanted.

I’m left wondering why green fails but Ruby works. Maybe it’s a timing issue because green is unpredictable whereas Ruby is synced to the stream. Dunno.

[tulamide]

If I actually made music with a DAW I would doubtless have realised the usage of the term “Bouncing” has changed. So it’s good to pick up on this type of information.

It hasn't really changed.
Bouncing means, what it always meant. Quick recording of a track with all its effects applied to another track. Running MIDI in this process just was an additional necessity because of modern instrument plugins. You still don't magically convert midi into audio, you record the instrument's audio output with all insert effects applied. Bouncing can (and is) be done with any number of tracks (even the whole mix) and is non-reversible.

But there is a new term that didn't exist before. "Freeze track". This is like a "bounce in place". It records the audio output with all insert effects applied, but the result is placed on the instrument track and the instrument and all insert effects deactivated afterwards. Freeze track is different to bouncing, as you can with just a click "unfreeze" the track, which deletes the recorded audio and re-activates the instrument and all insert effects in their last state.

Bouncing/freezing are still serving the same motivation. But where it was lack of available tracks back then, it is now lack of CPU power.


EDIT: I'm not saying that the following is the sole reason for it not working, but in your green solution you make a big mistake. You force integer values to be converted to floats and then compared for equality. But converting them means, you can't guarantee that they are exactly equal. Depending on the nearest presentable number from the float matrix, one number might be 1.00000001 and the other 0.9999999, which in the float realm of blurriness means they are "to be considered equal". Just use int comparators. Values won't be converted, you can asked for exact equality and the conversion back to ints also isn't necessary.

[kortezzzz]

EDIT: I'm not saying that the following is the sole reason for it not working, but in your green solution you make a big mistake. You force integer values to be converted to floats and then compared for equality

Indeed, that can be a problem. But the green midi issue proven to be related to midi green split. For example, if you try manipulating note's pitch from the midi stage by using green midi, youl'll end up with chopped and untuned notes as well. Try to play with the velocities by using the green midi and you get the same results.

By the way, Last working issues-free version is 3.06. 3.07 might also work properly, but I've never installed it to test. So at the current situation, MyCo said he has no idea where to start looking for it. This would be critical when new people gonna arrive and start learning FS with primitives, so I guess we better find what cause this before the FS4 becomes commercial.

[tulamide]

By the way, Last working issues-free version is 3.06. 3.07 might also work properly, but I've never installed it to test.

That explains why I didn't encounter it yet. I'm using 3.0.6 mainly.

So at the current situation, MyCo said he has no idea where to start looking for it. This would be critical when new people gonna arrive and start learning FS with primitives, so I guess we better find what cause this before the FS4 becomes commercial.

Wait. You mean that you split the signal, do a change, but when reading the midi signal afterwards it does not show the just changed note, but something more random?

[kortezzzz]

Wait. You mean that you split the signal, do a change, but when reading the midi signal afterwards it does not show the just changed note, but something more random?

No. It plays the manipulated notes and velocities normally. The problem only occurs when doing a bounce or an export to audio. In some cases (like in the attached video I made for MyCo), you may even end up with an almost blank audio track after bounce.

https://icedrive.net/0/c1ms5cPbud

[tulamide]

I think we can conclude that running MIDI at an undefined very high tempo leads to it, since bouncing runs afap. I just don't understand what changes in 3.0.7 or later could have introduced this behaviour. From the technical side of things I would have thought that Ruby might have problems (due to it only running at half speed in version >3.0.6 and <4). But green is event driven, it should react exactly as under normal (non-bouncing) circumstances. That's strange.
Is this effect proven on other DAWs as well? It might be a Studio One specific issue?

[Spogg]

Guys, thanks for sharing all this valuable information.

The midi split prim puts the midi data into the green world for processing. From what I see on the videos the bounce happens very quickly, much faster than real time. But surely green can’t go any faster just because a bounce is happening…?

I assume the DAW somehow expects the plugin to respond to midi data in a timely and consistently predictable way and this won’t be the case if green gets involved in midi message handling.

If I’m right and not talking nonsense, it will never be possible to fix in the green world. It would possibly need dedicated midi processing prims for common tasks. Of course Ruby can already do this but prims would be more comfortable than coding, especially for novices.

A question...
Am I right in thinking that “DAW midi” is restricted in the same way as “din midi”? Or can it run faster internally than the din system?

[tulamide]

Guys, thanks for sharing all this valuable information.

The midi split prim puts the midi data into the green world for processing. From what I see on the videos the bounce happens very quickly, much faster than real time. But surely green can’t go any faster just because a bounce is happening…?

I assume the DAW somehow expects the plugin to respond to midi data in a timely and consistently predictable way and this won’t be the case if green gets involved in midi message handling.

If I’m right and not talking nonsense, it will never be possible to fix in the green world. It would possibly need dedicated midi processing prims for common tasks. Of course Ruby can already do this but prims would be more comfortable than coding, especially for novices.

A question...
Am I right in thinking that “DAW midi” is restricted in the same way as “din midi”? Or can it run faster internally than the din system?

You are not quite right. Green is event based, that has nothing to do with the Windows timers that green offers. If you involve those timers you're out of the game, but without them it just reacts to an event (here split/heal midi) and it does that at whatever speed the events arrive. That's why buffering is so important (the audio buffer gives the system time to execute green events). That this system works flawlessly is proven by 3.0.6 which bounces without issues.

Your question: No, you're wrong. DIN Midi is fixed at 31250 bits per second. One MIDI message takes about 1 millisecond. If you send a "chord" of 7 notes, the 7th note arrives with the beginning of the 8th millisecond. This was already not fast enough in the 90s, let alone nowadays. That's where two things kick in. DAWs can be(and are usually by default) set to sync "internal". It is then freed from the 31250 bit/s limit. And the second thing is upcoming MIDI 2.0, because it allows for much higher speed over LAN, USB and the like. DIN cable MIDI is untouched though, to keep compatibility with MIDI 1.0

[kortezzzz]

That's very useful and interesting information, tula. Thank you.

Is this effect proven on other DAWs as well? It might be a Studio One specific issue?

I got complaints from reaper, cubase, FL studio and ableton users. Guess It's a quite indicates that it's not DAW related.

Another interesting thing:
Have any of you ever tried recording FS made midi arp \ sequencer that is seeded in a synth \ sampler on any DAW? Because if you didn't, I suggest to not even try. It won't work. The DAW ignores the internal independent arp \ seq's notes and the sequence remains only internal. The only way to record it is to create midi-out output in your synth and then to route the midi sequence through this midi output and record it to an additional opened midi channel in your DAW. Unfortunately, I've realize it too late and now have to re-design an entire project. I can only guess that DAWs ignore any midi signal that doesn't pass through their inputs. If you, for instance, trigger the internal arp with your hardware midi controller, the DAW will only record those triggering notes that coming from the controller, but not the sequence itself. So there is no sense in implementing an internal arp with on-off button.