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