Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

NEW REGISTRATIONS - please contact us if you wish to register on the forum

Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright

Filtering a specific midi channel from a packed midi event

For general discussion related FlowStone

Re: Filtering a specific midi channel from a packed midi eve

Postby adamszabo » Wed Feb 24, 2021 1:29 pm

My plugins bounce just fine, I guess it must be an issue with your plugins, or the way you created them. Just to clarify what happens when you "export" the clips? Does it render properly, or it only happens when you do this bounce thing in studio one
adamszabo
 
Posts: 667
Joined: Sun Jul 11, 2010 7:21 am

Re: Filtering a specific midi channel from a packed midi eve

Postby kortezzzz » Wed Feb 24, 2021 7:57 pm

adamszabo wrote:My plugins bounce just fine, I guess it must be an issue with your plugins, or the way you created them. Just to clarify what happens when you "export" the clips? Does it render properly, or it only happens when you do this bounce thing in studio one


According to my users report, it happens almost everywhere. Does your note's midi signal runs through any green midi path?
User avatar
kortezzzz
 
Posts: 763
Joined: Tue Mar 19, 2013 4:21 pm

Re: Filtering a specific midi channel from a packed midi eve

Postby adamszabo » Thu Feb 25, 2021 9:43 am

No, only ruby. But why dont you use ruby instead of green?
adamszabo
 
Posts: 667
Joined: Sun Jul 11, 2010 7:21 am

Re: Filtering a specific midi channel from a packed midi eve

Postby kortezzzz » Thu Feb 25, 2021 1:00 pm

adamszabo wrote:No, only ruby. But why dont you use ruby instead of green?


Yes, my comments are about that. I'm already using Ruby. But sooner or later, we will have to fix that green midi problem because new users of FS4 in the future will use greens and it won't work. Perfectly working green midi supposed to be a very basic feature.
User avatar
kortezzzz
 
Posts: 763
Joined: Tue Mar 19, 2013 4:21 pm

Re: Filtering a specific midi channel from a packed midi eve

Postby adamszabo » Fri Feb 26, 2021 12:44 pm

As I understand it was always known that greens are never supposed to be used for real time event based stuff, so its hard to fix a problem was was never meant to be a problem
adamszabo
 
Posts: 667
Joined: Sun Jul 11, 2010 7:21 am

Re: Filtering a specific midi channel from a packed midi eve

Postby kortezzzz » Fri Feb 26, 2021 1:52 pm

I can clearly see that green midi does supposed delivering real time performance, or the 3.06 made plugins wouldn't have ever succeeded to bounce a midi track. But they do. It's just something went wrong in the next betas and never fixed. We have no idea what and when exactly it happened or who was the DSPR coder that messed with that by a mistake. We only know that it happened somewhere between 3.06 and the start point of the alfa production.
User avatar
kortezzzz
 
Posts: 763
Joined: Tue Mar 19, 2013 4:21 pm

Re: Filtering a specific midi channel from a packed midi eve

Postby HughBanton » Sun Feb 28, 2021 11:52 am

tulamide wrote: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.

1mS is certainly true for a single note, but a chord goes much faster under Running Status. Here's how it works :
'MIDI bytes' comprise a start bit, an 8-bit number, and then a stop bit = 10 bits per package. So a package gets transmitted in (1 / 31250 * 10) mS, = 0.32mS. A single Note-On comprises Status Byte, Note Number, Velocity, so gets transmitted in 3 * 0.32 = 0.96mS, call it 1mS.

Now I suspect some confusion may have crept in about Running Status. It has nothing directly to do with that 'Note-On, Velocity = 0' thing; but it does indirectly .. back to that in a mo.

Running Status allows way fewer Status bytes to be sent, and it tells the MIDI receiver "if you're expecting a Status Byte next, and none turns up, just continue with the last one you received". So .. for the 7-note chord, instead of sending
Status, Number, Velocity; Status, Number, Velocity; Status, Number, Velocity; .. etc, = 21 MIDI bytes
it just sends
Status, Number, Velocity; Number, Velocity; Number, Velocity; Number, Velocity; .. etc. Only 15 MIDI bytes.

Therefore under Running Status our 7-note chord gets transmitted in 15 * 0.32 = 4.8mS.

So, adding "Note-On with Velocity=0" into the scheme of things means that only Note-On status bytes ever get sent - no Note-Off status bytes getting in the way. Once it's received just a single 'Note-On' byte, Running Status can continue uninterrupted ad infinitum, just Number, Velocity; Number, Velocity; Number, Velocity .......

Until you go and use the Pitch Wheel. Or Aftertouch. Dang! :roll: C'mon MIDI 2.0

H
User avatar
HughBanton
 
Posts: 265
Joined: Sat Apr 12, 2008 3:10 pm
Location: Evesham, Worcestershire

Re: Filtering a specific midi channel from a packed midi eve

Postby tulamide » Sun Feb 28, 2021 4:51 pm

HughBanton wrote:
tulamide wrote: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.

1mS is certainly true for a single note, but a chord goes much faster under Running Status. Here's how it works :
'MIDI bytes' comprise a start bit, an 8-bit number, and then a stop bit = 10 bits per package. So a package gets transmitted in (1 / 31250 * 10) mS, = 0.32mS. A single Note-On comprises Status Byte, Note Number, Velocity, so gets transmitted in 3 * 0.32 = 0.96mS, call it 1mS.

Now I suspect some confusion may have crept in about Running Status. It has nothing directly to do with that 'Note-On, Velocity = 0' thing; but it does indirectly .. back to that in a mo.

Running Status allows way fewer Status bytes to be sent, and it tells the MIDI receiver "if you're expecting a Status Byte next, and none turns up, just continue with the last one you received". So .. for the 7-note chord, instead of sending
Status, Number, Velocity; Status, Number, Velocity; Status, Number, Velocity; .. etc, = 21 MIDI bytes
it just sends
Status, Number, Velocity; Number, Velocity; Number, Velocity; Number, Velocity; .. etc. Only 15 MIDI bytes.

Therefore under Running Status our 7-note chord gets transmitted in 15 * 0.32 = 4.8mS.

So, adding "Note-On with Velocity=0" into the scheme of things means that only Note-On status bytes ever get sent - no Note-Off status bytes getting in the way. Once it's received just a single 'Note-On' byte, Running Status can continue uninterrupted ad infinitum, just Number, Velocity; Number, Velocity; Number, Velocity .......

Until you go and use the Pitch Wheel. Or Aftertouch. Dang! :roll: C'mon MIDI 2.0

H

I do understand running status (working with MIDI since 1990). However, DAWs don't use running status, and Flowstone doesn't use it either. It was just a very bad shortcut to save a bit of time after realizing that the protocol is far too slow over DIN cable. Try this: Send 16 notes, each on its own channel (don't forget, MIDI is a multichannel protocol). Enjoy ;)

We don't have to worry about running status at all nowadays. As I said, DAWs are sync'ed internal, they are transmitting MIDI between plugins (or even over LAN as Reaper does) so much faster than MIDI DIN cable ever could. That's also why DAWs don't bother with running status. They support it for external gear (internally repacking them into a complete message again), but they don't use it themselves. You can literally send thousands of full MIDI messages in a mS on a PC.

Nobody in 2021 would seriously try to argue that MIDI 1.0 is fast enough. It's stuck to the technology of the late 80s. Over 30 years of development in hardware and software has made it a relic. Imagine we would still need to use the serial bus instead of USB 3.1 gen 2!
"There lies the dog buried" (German saying translated literally)
tulamide
 
Posts: 2714
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: Filtering a specific midi channel from a packed midi eve

Postby HughBanton » Sat Mar 06, 2021 1:08 pm

My next planned project is an Arduino USB MIDI controller that I've convinced myself I need. I won't go into that here (wrong forum!) but as a result I have been studying USB over MIDI a bit, so some insights to offer.

First off, USB runs at 12Mbits/sec, up to 40Gbits/sec for the latest type - werhey, so in MIDI terms - compared to DIN plugs at 31250 - we can regard that as zero latency! I read that USB-MIDI is sent in packets of 64 bytes, some of which contain the data we're familiar with .. 144, 128, velocity values, controller numbers and so on. Tulamide is correct - no running-status tricks are needed at this sort of data rate, so each packet is always sent fully loaded and complete: status byte, data or message.

The conversion from DIN MIDI to USB MIDI (and back) is carried out in your interface box, where the slow DIN messages become fast USB messages. What Flowstone then does after parsing these packages is up to the programmer, so is unbeknownst to us mere mortals, and only knownst unto the likes of Maik & Malc. Same with e.g. Reaper, knownst only to the Cockos team.

However snag .. USB-MIDI has to have a host, i.e. your PC, and you can plug several items in at the same time - keyboards, controllers etc. BUT, if you want to connect one keyboard to another, do any complicated thrus or merges or suchlike, the only simple option is still the old DIN plug method.

Where running-status is still alive and kicking. It's worth knowing that ..

if
- your keyboard does running status &&
- your keyboard supports 'note-on with zero velocity = note-off' &&
- it doesn't feature after-touch &&
- you don't touch the pitch wheel
then
- the first note will transmit in 0.96mS, + subsequent notes will transmit in 0.64mS (only sending 2 bytes)
end

Not too serious, and up to 33% faster than it would be without running-status.
Oh, and don't press 7 notes down at exactly the same moment ;)

H
User avatar
HughBanton
 
Posts: 265
Joined: Sat Apr 12, 2008 3:10 pm
Location: Evesham, Worcestershire

Previous

Return to General

Who is online

Users browsing this forum: No registered users and 111 guests