|
keystep, yes, have a 37 on the way :-D (made a decision at last)
this is an interesting option for QYs: you can never hear the other parts in step mode, right?
(i can't think of a sequencer that DOES trigger other parts as you step through)
anyway: any supplementary sequencer input seems like it could be pretty wicked. ...
|
Hi,
?Don't know the reply to that, so I asked midhubs forum and got this reply from the developer.
"Hey, the amount of messages per second is limited by MIDI bandwidth which is 3125 bytes per second. Most messages are 3 bytes long. Bursts of data when it exceeds the bandwidth (for example when merging multiple MIDI inputs to single output) get queued, and sent out as soon as possible, so data is not lost. SysEx merging is also queued, so multiple transactions don¡¯t overlap each other."
?I have no affiliation with midihub, it was a quest that started with "I need a midi router" and ended with "should have bought this long time ago".
Best,
Daniel
toggle quoted message
Show quoted text
On 18/02/21 09:42, kaltar wrote: That is one nice box, never saw it before. However (1) it is not really programmable and (2) It gets power from MIDI . Avoid those at all costs!
I think the MidiHub is the only equivalent to the MEP4. The MEP4 gets an error if you surpass 1000 messages per second (the internal buffer overloads). And while that is never an issue with a single keyboard, it does happen a lot when using a sequencer with lots of modulations going on.
On Feb 18, 2021, at 3:01 AM, Daniel Branco <daniel@...> wrote:
?Hi,
No issues with it so far. It's a pretty refined tool by now. (still being maintained on the software and firmware side)
You will find many applications for it besides filtering.
When searching, found this but it I think it wont solve your issue.
Best,
Daniel
On 17/02/21 21:59, kaltar wrote:
Thanks Daniel. I¡¯ve seen the Midihub before and seems like a good alternative. Is it the only one you know of? Have you had any crash?
Kaltar
|
Thanks for the info Daniel. Due to your prior email recommending it I already ordered one, and it¡¯s on its way from Lithuania.
About midi bandwidth: Many devices do not respect it and just go faster (UM-880 as an example. Sends sysex faster than some devices can read, that¡¯s why I keep a couple of ancient backup interfaces. and it can receive faster than the protocol specifies). With just one track of heavy poly aftertouch I am already at the limit, and using many fingers, The Linnstrument produces more than 3000 per second . The midihub shouldn¡¯t have a limit on incoming data, but they are citing the same speed of the MP4!
As long as data gets queued and does not crash, all will be ok. That¡¯s why Im getting only one to test it first.
toggle quoted message
Show quoted text
On Feb 19, 2021, at 3:29 AM, Daniel Branco <daniel@...> wrote:
?Hi,
Don't know the reply to that, so I asked midhubs forum and got this reply from the developer.
"Hey, the amount of messages per second is limited by MIDI bandwidth which is 3125 bytes per second. Most messages are 3 bytes long. Bursts of data when it exceeds the bandwidth (for example when merging multiple MIDI inputs to single output) get queued, and sent out as soon as possible, so data is not lost. SysEx merging is also queued, so multiple transactions don¡¯t overlap each other."
I have no affiliation with midihub, it was a quest that started with "I need a midi router" and ended with "should have bought this long time ago".
Best,
Daniel
On 18/02/21 09:42, kaltar wrote:
That is one nice box, never saw it before. However (1) it is not really programmable and (2) It gets power from MIDI . Avoid those at all costs!
I think the MidiHub is the only equivalent to the MEP4. The MEP4 gets an error if you surpass 1000 messages per second (the internal buffer overloads). And while that is never an issue with a single keyboard, it does happen a lot when using a sequencer with lots of modulations going on.
On Feb 18, 2021, at 3:01 AM, Daniel Branco <daniel@...> wrote: ?Hi,
No issues with it so far. It's a pretty refined tool by now. (still being maintained on the software and firmware side)
You will find many applications for it besides filtering.
When searching, found this but it I think it wont solve your issue.
Best,
Daniel
On 17/02/21 21:59, kaltar wrote:
Thanks Daniel. I¡¯ve seen the Midihub before and seems like a good alternative. Is it the only one you know of? Have you had any crash?
Kaltar
|
Queing for some sysex or CC messages makes sense, but generally speaking if a message is late (like a note or a n lfo sweep) it will likely make the song sound worse than had it never arrived.
Crashing is obviously the worst, but personally I think there should be a light to indicate overflow... like the clipping light on a mic input. ? It certainly would make debugging midi channels alot easier.?
BTW, I just picked up a few WIDI jacks that should arrive soon, they are pretty cool (on paper anyway) as they not only do wireless point-to-point out of the box, they can also do a star network pattern where one jack can talk to upto 4 others. ? Plus they are MIDI *or* USB powered... which is the best of both worlds IMHO.?
In regards to any MIDI box purchase (from any vendor) you might to make sure the device is supporting the new MIDI spec... ?it finally goes far beyond the 33K data speed. ?
Here¡¯s a link if anyone is interested: ? (Note: Shipping per unit is a bit pricey IMHO, but becomes a bit more reasonable if you order several)
Disclaimer: I am not associated to CMI (makers of WIDI Jack) except as a customer. Cheers, Eric
["The longest journey starts with the first step."?- Lao Tzu]
toggle quoted message
Show quoted text
On Feb 19, 2021, at 5:46 AM, kaltar <kaltar@...> wrote:
? Thanks for the info Daniel. Due to your prior email recommending it I already ordered one, and it¡¯s on its way from Lithuania.About midi bandwidth: Many devices do not respect it and just go faster (UM-880 as an example. Sends sysex faster than some devices can read, that¡¯s why I keep a couple of ancient backup interfaces. and it can receive faster than the protocol specifies). With just one track of heavy poly aftertouch I am already at the limit, and using many fingers, The Linnstrument produces more than 3000 per second . The midihub shouldn¡¯t have a limit on incoming data, but they are citing the same speed of the MP4!As long as data gets queued and does not crash, all will be ok. That¡¯s why Im getting only one to test it first.On Feb 19, 2021, at 3:29 AM, Daniel Branco <daniel@...> wrote:
?Hi,
Don't know the reply to that, so I asked midhubs forum and got this reply from the developer.
"Hey, the amount of messages per second is limited by MIDI bandwidth which is 3125 bytes per second. Most messages are 3 bytes long. Bursts of data when it exceeds the bandwidth (for example when merging multiple MIDI inputs to single output) get queued, and sent out as soon as possible, so data is not lost. SysEx merging is also queued, so multiple transactions don¡¯t overlap each other."
I have no affiliation with midihub, it was a quest that started with "I need a midi router" and ended with "should have bought this long time ago".
Best,
Daniel
On 18/02/21 09:42, kaltar wrote:
That is one nice box, never saw it before. However (1) it is not really programmable and (2) It gets power from MIDI . Avoid those at all costs!
I think the MidiHub is the only equivalent to the MEP4. The MEP4 gets an error if you surpass 1000 messages per second (the internal buffer overloads). And while that is never an issue with a single keyboard, it does happen a lot when using a sequencer with lots of modulations going on.
On Feb 18, 2021, at 3:01 AM, Daniel Branco <daniel@...> wrote:
?Hi,
No issues with it so far. It's a pretty refined tool by now. (still being maintained on the software and firmware side)
https://community.blokas.io/t/download-midihub-editor-1-11-8-firmware-1-11-10/2730
You will find many applications for it besides filtering.
When searching, found this https://www.thomann.de/intl/miditech_midi_thru_filter.htm but it I think it wont solve your issue.
Best,
Daniel
On 17/02/21 21:59, kaltar wrote:
Thanks Daniel. I¡¯ve seen the Midihub before and seems like a good alternative. Is it the only one you know of? Have you had any crash?
Kaltar
--
¡°The longest journey starts with the first step." ?- Lao Tzu
|
Hey Eric,
Indeed, queueing a midi message will introduce a delay. midi delay using 5-pin DIN is a fact, but we often ignore how much of a delay it is!
MIDI 1.0 speed: 31.25 kb/s = 3906.25 words/s
Since Note ON/Note OFF/CC midi messages(mm) are all 3 bytes, we get an average speed of: 1302 mm/s, or 1.302 mm/ms, or 13/10 mm/ms, or 13 mm per 10 ms Or 1 mm = 10/13 ms.
So a keyboard playing a chord 1/3/5/7/9/13 , all 6 notes played at the same time, will be outputted in serial order, with the last note at 4.6 ms. A super fast sweep of the mod wheel in 1ms, assuming it transmits all the values 0-127 without skipping, will be transmitted in 98.46ms. If we add our chord, we have already over 1/10 seconds of delay. That is, without a doubt, noticeable. And that is just one cable! What about sending the same message via midi thru, or hardware splitter, to 16 synths in one cable? That is 1.6 seconds of latency. Incredible! And that is without queuing! Straight from a keyboard and without taking any other device in the middle. This is a reason to support both USB MIDI (Same protocol but way faster speeds, however may include extra latency/jitter), modular analog synths (0 delay) and DAWs using VSTs (most daws automatically adjust latency for 0 delay on VSTs output).?
But being honest, our example is heavily exaggerated, since a full sweet is never that fast (a 100 ms sweep is really fast, a 1ms sweep is programmed only). And even at 100ms, we still have many midi messages to spare (they go between the sweep messages). I use multiple synths (10) with just one cable, and move multiple CC changes in each synth without a hiccup. I have only experienced issues with some heavy continuous data (like multiple poly aftertouch, or regular use of the linnstrument will exceed this limit). This is a reason to keep each synth on a different cable, and the main question I had with the midihub: Max input speed, which makes sense has to be the same as the output, since it¡¯s done in 5-pin Din.?
Decades ago, never heard complains of the tightness of drums via MIDI, only until the DAW era. The latency/jitter of the DAW midi interface before each single message can make it really high. But using just midi DIN on a no-latency drum machine, 6 percussion elements at the same beat, it will be 4.6ms delayed, and that may be noticeable, at least to some people.
MIDI devices have 3 options on RX overflow (exceeded MIDI bandwidth on INPUT): Queuing, Crashing or Ignore. But ignore is really hard to program, since you do not know if a NOTE OFF message was received. This will leave voices hanging (that¡¯s why the PANIC button was added early on MIDI synths/devices). Crashing is the worst, because will stop ALL data flow until the device is reset, and still need PANIC buttons.The optimal is always QUEU, since you can hear if you are sending too much msgs. (Make a test of tons of modulation 0-127 on 16 tracks that you can hear, and go against a beat on another track. you will definitely hear how the MIDI device will take time to catch up.
BTW, this is a nice study measuring MIDI latency and perceptual latency of sound via MIDI.
Widi jacks: they advertise as low latency (3ms), however that is the best case scenario! Plus jitter DOES happen! And disconnections? Im always dubious of wireless transmissions.
Stay safe, Kaltar
toggle quoted message
Show quoted text
Queing for some sysex or CC messages makes sense, but generally speaking if a message is late (like a note or a n lfo sweep) it will likely make the song sound worse than had it never arrived.
Crashing is obviously the worst, but personally I think there should be a light to indicate overflow... like the clipping light on a mic input. ? It certainly would make debugging midi channels alot easier.?
BTW, I just picked up a few WIDI jacks that should arrive soon, they are pretty cool (on paper anyway) as they not only do wireless point-to-point out of the box, they can also do a star network pattern where one jack can talk to upto 4 others. ? Plus they are MIDI *or* USB powered... which is the best of both worlds IMHO.?
In regards to any MIDI box purchase (from any vendor) you might to make sure the device is supporting the new MIDI spec... ?it finally goes far beyond the 33K data speed. ?
Here¡¯s a link if anyone is interested: ? (Note: Shipping per unit is a bit pricey IMHO, but becomes a bit more reasonable if you order several)
Disclaimer: I am not associated to CMI (makers of WIDI Jack) except as a customer. Cheers, Eric
["The longest journey starts with the first step."?- Lao Tzu]
On Feb 19, 2021, at 5:46 AM, kaltar <kaltar@...> wrote:
? Thanks for the info Daniel. Due to your prior email recommending it I already ordered one, and it¡¯s on its way from Lithuania.About midi bandwidth: Many devices do not respect it and just go faster (UM-880 as an example. Sends sysex faster than some devices can read, that¡¯s why I keep a couple of ancient backup interfaces. and it can receive faster than the protocol specifies). With just one track of heavy poly aftertouch I am already at the limit, and using many fingers, The Linnstrument produces more than 3000 per second . The midihub shouldn¡¯t have a limit on incoming data, but they are citing the same speed of the MP4!As long as data gets queued and does not crash, all will be ok. That¡¯s why Im getting only one to test it first.On Feb 19, 2021, at 3:29 AM, Daniel Branco <daniel@...> wrote:
?Hi,
Don't know the reply to that, so I asked midhubs forum and got this reply from the developer.
"Hey, the amount of messages per second is limited by MIDI bandwidth which is 3125 bytes per second. Most messages are 3 bytes long. Bursts of data when it exceeds the bandwidth (for example when merging multiple MIDI inputs to single output) get queued, and sent out as soon as possible, so data is not lost. SysEx merging is also queued, so multiple transactions don¡¯t overlap each other."
I have no affiliation with midihub, it was a quest that started with "I need a midi router" and ended with "should have bought this long time ago".
Best,
Daniel
On 18/02/21 09:42, kaltar wrote:
That is one nice box, never saw it before. However (1) it is not really programmable and (2) It gets power from MIDI . Avoid those at all costs!
I think the MidiHub is the only equivalent to the MEP4. The MEP4 gets an error if you surpass 1000 messages per second (the internal buffer overloads). And while that is never an issue with a single keyboard, it does happen a lot when using a sequencer with lots of modulations going on.
On Feb 18, 2021, at 3:01 AM, Daniel Branco <daniel@...> wrote:
?Hi,
No issues with it so far. It's a pretty refined tool by now. (still being maintained on the software and firmware side)
You will find many applications for it besides filtering.
When searching, found this but it I think it wont solve your issue.
Best,
Daniel
On 17/02/21 21:59, kaltar wrote:
Thanks Daniel. I¡¯ve seen the Midihub before and seems like a good alternative. Is it the only one you know of? Have you had any crash?
Kaltar
-- ¡°The longest journey starts with the first step." ?- Lao Tzu
|
Daniel Branco
Eric