Forum Replies Created
-
Posts
-
With my panel I use for NRPN (for example): F0 B0 0D xx 7F, so it is a sysex message which you have to start with F0 and end with 7F. The bold part of the message is device dependent (of course).
Ah, I get it. So if I want to mimic this behaviour exactly, should I use something like MouseDown and MouseUp commands in Lua, which would increment the value as long as the user keeps the mouse button pressed?
Well, I did download the latest Mac build, 5.3.85 and this one doesn’t have the compile errors for json4lua and debugger.lua. Finally the panel behaves as expected. So consider my previous message as ‘not written’ ;-)! BTW: the Mac OS X build with the mentioned errors is version 5.2.100.
Please sit to do the Mac OS builds and hopefully you can also address the json4lua and debugger.lua compile problems I mentioned earlier! Of course I respect your free time after work, so don’t take my “screaming” too literally 😉
Thanks for the reply! Do you mean by the second error the one generated on Windows 7?
Maybe related. With the SAME panel I have issues with CTRLR 5.3.116 (latest build) on Windows 7. To me (as not an experienced programmer) these error message is fairly incomprehensible! See attachment for the error message.
reminds me exactly of my issue some 4 months ago… http://ctrlr.org/forums/topic/panic/
maybe some of the similarities can help you (atom) to discover the cause (and solve the problem ;-).Well, I’m not sure but all this crashing reminds me of my own crashing hell experiences on my Mac a few months ago. Look at this topic: http://ctrlr.org/forums/topic/crashing-hell-on-mac-please-help/
and then especially towards the end of the topic where atom mentions an issue with the Apple LLVM compiler… But maybe I’m totally wrong. If so, my apologies!You’re right about the Porta Mode. I corrected this error and uploaded v.0.941, but it is easy to correct it yourself. Just reverse the button values (text in this case). Thanks for finding this error!
@hooya: I loaded the latest uploaded version (vSWBPian0.94, the exported binary compressed) in CTRLR to be sure I’m using the one you use and the Program Change slider is working OK in my setup. Make sure your sending the program change message on the midi receiving channel of the TX7. In my setup everything is setup for channel 1.
About your renaming feature request, I studied the Unisyn patch editor and it seems possible, but only (at least that’s what I have found out so far) by sending ALL 32 voice data to the TX7 (including then of course the new name(s)). I will look into it, but next month I’m away for at least 4 weeks (maybe longer) and I’m not sure yet if I take the TX7 with me to do some more panel developing…
I have just uploaded v0.94 of the TX7 panel. I corrected a few errors and added a program change slider (which was no big deal…). For the voice data the panel seems now to be stable. See for more information my text for the panel in the panel download area.
Many thanks for the input and testing. As usually much appreciated! You should know that I modeled this panel (almost) in the same way as the Unisyn patch editor for TX7 (made by MOTU) for Mac. Unisyn is working perfectly on my Mac PPC7600 and because it is a professional product from MOTU I trust they programmed it in the right way. Unisyn has a midi monitor for sending and receiving midi data. This way I know exactly which sysex message each modulator should be sending and also I know which sysex messages to use for the dump requests. So no mistakes in that area. @atom: So I’m pretty sure I’m using the right “Format Number” for these requests.
By further testing this panel I found two mistakes in the range assignment for the ‘detune’ modulator and the ‘k.vel sens’ modulator. @hooya: So this confirms your findings! I corrected these errors and now the received voice data don’t change anymore on the second click.
The performance data are also stable except for wheel, foot, aftertouch and breath control settings. They seem all the time to fall back to some default value. (I still need to find out how to extract a bit from the received byte in order to set the buttons for these controllers to on or off depending on the received byte value.)
@atom: AFAIK I’m already breaking the dump data into three parts: voice, name and performance, using a if..then statement in my script.
So all in all the panel is now quite stable, at least in my setup with this particular (hopefully unbroken) TX7.
I will soon upload this updated panel (and probably add a ‘program change’ slider as a bonus ;-)). When I find the time I will make this panel also VST proof.IF you download the latest version, you see two buttons on the panel: ‘get patch’ and ‘get perf.’. When clicking those buttons a sysex message is send, requesting a voice bulk dump and a performance bulk dump. (If you own the TX7 manual, the format for these request is on page 35.) The Lua script receiving these data processes the parameter data based on the two different sizes of the dump: 163 for voice data and 102 for performance data. The script does its work and assigns each parameter value to the concerning modulator (and shows in the process also the voice name on the panel). You see the sliders change their positions. I check the incoming data with the midi monitor of CTRLR and when I click a second time on each button (still with the SAME voice present on the TX7) I see of course again incoming midi data. I would say then about 95% of the data is the same as the previous, but a few data values are always different (both for the voice data and the performance data) and therefore some modulator sliders change again their position because of these different values. What puzzles me is why the incoming midi data from the TX7 do change in between, while I’m doing nothing in between. Maybe (but how/why?) the second bunch of data (requested btw with the SAME bulk dump message) come from another memory location in the TX7 device?
I have uploaded the latest version. I changed the Lua script to check on size. I confirmed that my TX7 is sending the right size of bytes for the patch dump and performance dump. Still the modulator values change when clicking a second time on the patch and performance button (I separated now these buttons). Which is odd, because I’m always sending the same dump request message. So it seems the TX7 is changing the parameter bytes in between requests? Probably not, but something is going on and it beats me!
Yes, I know user friendliness is important, but first I like this panel to function without problems in my setup. Maybe you have a point in suggesting that there could even be something wrong with my particular TX7… So it is indeed a good idea to put in checks for if the whole dump is received or just parts of it. Thanks.
