midi thru messages are very untight
Create custom control surfaces for MIDI hardware.
Status: Beta
Brought to you by:
ctrlr
Menu
▾
▴
#172 midi thru messages are very untight
open-accepted
nobody
None
5
2012-02-15
2012-02-15
Anonymous
No
yes, midi channelize (when thru is activated) is a very cool improvement.
but the timing of midi messages seems to be very untight/odd (sometimes midi notes have a delay about more than 70 ms!!). also it seems to affect the tightness if you do several things with your mouse/host/computer - then ctrlr will get more and more out of the groove...
midi thru is nice, but at the moment it's "useless" when midi notes comming through it (much too flaky and untight).
Discussion
This will always be the case for Ctrlr, it is impossible to time messages from the host to the MIDI Device, there is no mechanism that can do that. I can try to make it better but the problem will never go away. This is not my fault, this comes from the architecture of the VST/AU format. I'll keep this bug open for now and try to make this better.
"this comes from the architecture of the VST/AU format."
which vst/au plugins do you mean? all plugins i'm using are (almost) 100% tight.
even pure midi plugins (ie midiChannelize from piz midi plugins) are tight, try the piz midi tools.
a rarely inaccurateness about 1-2 ms would be acceptable (but it should happen rarely).
an inaccurateness about more than +/- 70 ms (ctrlr) changes the groove structure completely!
would be nice if you could change the (MAX) delay to 1-2 ms. already 3-5 ms is hearable (=useless, unless you're looking for an ungroovy random sound).
This is true for MIDI that does not leave the host (this can and will be done better). But it is not true for plugins that receive midi from the HOST and transmit them to a MIDI Device directly. It is impossible to time them correctly (you can do some assumptions on when to send them but there is no guaranteed way to do this).
really strange. because i've worked a lot with midi plugins and never had such timing problems, i did some tests and compared the piz midi plugins with ctrlr:
- i created 2 midi tracks in ableton live
- in one track i opened a piz midi plugin (a note transposer) which send it's midi data directly to the synth
- in the other track i opened ctrlr with "thru" enabled, so it's also sending it's data directly to the synth
- then i set some midi notes, and copied them to both midi tracks
- to gain a visual feedback i recorded both tracks as a long audio file...
sorry, but in compare to ctrlr, the piz midi plugins are (almost) 100% tight! rarely i noticed a delay of 1-2 ms (max). its very possible that you're completely right, that a midi vst/au (which get its notes from the host and sends them directly to the midi device/synth) can't be 100% tight - but 99,9% seems to be possible! otherwise (if a heavy inaccurateness is standard/usual) i really wonder why people are using midi plugins which always completely destroy their grooves. i'm confused!
I never assumed for Ctrlr to be time accurate so that's the problem. It's a synth editor those features you talk about were never my priority, but i understand that they should be for some users (most of users expect different things from Ctrlr). I'll work on that and let you know (i'm working on it at the moment)
ok, thanks. i guess a lot of people will get a benefit if the timing is stable. i did some further testings, and i wanted to let you know - maybe it's helpful for you:
the most inaccurateness in terms of timing happens (also note lenghts get cutted) when "working" with the host/daw. in ableton live 7 many operations affect the "tightness" like recording clips and stop recording. when i' resizing the ableton live window, the midi notes get totaly stucked - almost nothing is hearable anymore. i know it's an extreme situation, but also "small" operations affect the timing. maybe this info could be helpful to find a (main?) problem?
I actually know exactly why this is happening (this is all because of the Threading model Ctrlr has). I need to change that and after that we can try to make that better, there is nothing that can be done with the existing model.
oh, that sounds like a lot of work (also the other things you're working on)! hope your hard work will solve some problems. of course i'm here when it comes to testing...
hi. i recognised that you've uploaded some new releases. possible that something went wrong? the "new" versions seem to be the same like the uploaded versions from january (933/934, 27.01.2012).