external program change cuts midi in connection
Create custom control surfaces for MIDI hardware.
Status: Beta
Brought to you by:
ctrlr
Menu
▾
▴
#144 external program change cuts midi in connection
when i am doing several program changes (doing it multible times) on my external synth the midi in connection (from synth to ctrlr) doesn't work anymore. no midi messages are received by ctrlr anymore, its completely broken. a work around is: enter edit mode, leave edit mode. then the midi in connection is working again, but this can not be a solution. please fix it in a new stable version.
Discussion
is this fixed in the latest version?
is a stable midi connection really that unimportant (for a MIDI-DEVICE!!)??
i really don't understand why you always ignore BASIC bugs. it seems much more important for you to pimp up ctrlr amost just with optical enhancements.
ok it's your project! but i'm tired of searching bugs which are always ignored... bye
what panel are you using, what version of Ctrlr and what OS are you running.
of course an empty / new panel, of course the latest version (atm 910) - and os x 10.6
I checked this yesterday and i couldn't reproduce this. Check if the incoming midi gets to the MIDI Mon after the break occurs, the MIDI Mon listens directly on the hardware port before any processing is done. Also maybe you can ask some people on the forum if they're getting the same problems. I'll be able to help only if i can reproduce this here.
yes the incomming midi gets still to the midi mon, even if the midi in connection is already broken.
"I checked this yesterday and i couldn't reproduce this. "
are you realy sure that you checked it intensive enough?? i'm watching the forums since ctrlr v4 and i know how complicated it is to get you accepting bugs - and v4 was a bug monster!
as i told it doesn't happen with each program change. sometimes the connection breaks after 3 program changes, sometimes after 30. so be patient!
i will not writing to the forums because i already gave up ctrlr v5 (at least for now). it's too much work to get you accepting bugs - but this one is real (since a loooong time)!
and often you also like to ignore people who just want to help finding bugs, this is back-breaking!
it's too bad that you're not 100% interessted in fixing ctrlr - nobody needs software which doesn't work in it's main purposes. and so i do.
i accept bugs i can reproduce. I was sending program changes for a few minutes and nothing happened.
If the MIDI in messages appear in the MIDI Mon it means that Ctrlr is receiving them, what happens when the connection breaks if the panel is empty what happens ?
If you do not wish to follow up on this please let me know i will close this bug report.
"what happens when the connection breaks if the panel is
empty what happens ?"
i'm not sure what you mean exactly. If the panel is empty so no component is inside/set? of course nothing happens, but also nothing will happen if the midi connection WORKS... so what do you mean?
please try to send some program changes again, because i found out that (if the midi in connection is already broken) and then you send some program changes again, SOMETIMES the midi connection works/is repaired again! so it's very possible that maybe your connection broke and because of further program changes it worked again!
and no i'm not interessted in closing this bug report. unless this report seems unimportant for you.
I need to reproduce this problem, can you send an example panel that you test it with, and perhaps a log of midi events that lead to the error, i'll be able re-play the situation and see what's going on.
i uploaded an example panel and a text file of the midi events. hope it helps.
sorry. upload didn't work. how do i do this?
Just mail it to me kubiak.roman [at] gmail[dot]com
did you looked into that issue? it seems that the midi in connection is much more stable in the latest version. thanks!
it seems that my joy was a bit too early.
the midi in connection for all parameters besides program change seems to be stable in 927. nice
BUT: since 927 ctrlr (it's components) doesn't receive program change data anymore (though the midi monitor is showing them). i've tried it with sliders and combos. none of them receiving program changes anymore. before 927 this was not a problem.
I've added a new option to the panel properties that filters some types of MIDI messages from beeing matched to components, by default program changes are excluded have a look at that list and uncheck program changes. But this will revert to the behavior before the change.
ok, i see. but does that mean it is not possible to receive program changes anymore (otherwise the midi in breaks = inacceptable)? i mean: program change is a very basic command. only when ctrlr is receiving program changes, it is possible to send the right program change message on startup, to set the synth to the dedicated sound.
It should be possible i'm still working on that problem, this is a solution for other problems but might help you until a permanent fix is in place.
nice. i would be glad if the midi in/out connection will be completely stable.
very good, program changes doesn't seem to crash the midi in anymore (933). though it seems that some other midi messages still crashing the midi in. i found out one further message (volume):
[MIDI IN ][15:09:12:000244]: [FastLane USB Port B][184 007 098]
[MIDI IN ][15:09:13:000621]: [FastLane USB Port B][184 007 097]
hope you can eliminate this problem, too (volume is also a basic command).
If you are interessted i could try to find (in the future) more messages and write them down here. but for the moment i only could find the message above.
I know where the problem is and i'm trying to find a good fix for it, there is really no crash the midi input works fine it's the message matching algorithm that's failing.
Some readers might think there is a lot of information to digest in this article. I think its so clear and well formatted that its easy to read and digest. This writing is nicely done.
<a href="http://carol1son.blogoak.com?blogname=carol1son&postarch=3" title="divine">divine</a>
Since i couldn't reproduce this problem i can't say if it's fixed or not.