- This topic has 18 replies, 3 voices, and was last updated 10 years, 10 months ago by
.
-
Posts
-
For those who have downloaded my TX7 panel: I have changed the accompanying explanatorily text to reflect better the beta status of this panel. As a matter of fact I’m pretty stuck at the moment, because I can’t find the reasons why some modulators behave the way they do. Maybe someone can help? Also I would very much appreciate it if someone could help me with writing a Lua script to save in/load from a file a preset (or a bank for that matter) for the TX7. (I am right that you can not save a preset on the TX7, unless you use a cassette recorder?)
Today (May 20) I uploaded the latest update for this panel (v0.92 beta). Wrong settings for some modulators were corrected and I added a new block: function parameter change. These functions can sometimes be useful.
I downloaded the panel, the first thing i notices is your Lua method. It start with
midiReceived = function(midi) midiParam = midi:getData():getByte(5)
You should never access data at a certain position without checking if the dat is there. That is you should first check the data size and then you can access it (use midi:getData():getSize() to check the size). With that check you can follow up checking the prefix of the message to make sure it’s the correct format, in case any of those checks fails, you should exit the method.
OK, thanks for your comment and advice. I will look into it asap!
Also failures in those checks should be somehow communicated to the user. Especially for devices from the 80s/90s. Back then midi data errors were frequent, and sometimes with those devices incomplete messages might happen, broken devices may produce bad data or fragment it. If the user knows what happened (incorrect format, incomplete data) it might help them diagnose the problem.
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.
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!
Can you be more specific what’s wrong. Witch buttons (on the device or on the panel?). Walk me through the process.
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?
From what i see in the manual you should determine the type of data received by the “Format Number” byte in the message received.
I recommend writing a separate method for parsing each part (voice data, perf data, voice name).
You used names of modulators for enumarating by appending a number to them, i wouldn’t do that, imagine that you will export this as a VST plugin and want to do automation in the host, the parameter list will be unreadable. Each modulator has 2 special properties for this purpose that i recommend using “Custom modulator index group” and “Custom modulator index”, you can use those properties to group and access your modulators. Rename your modulators to something human readable.
It looks like you hard coded the voice data to 0 that’s the edit buffer, and that will change anytime you move a slider on the panel, so if you do a request->move some sliders->do a request the data should be consistent (that is no slider should change on the second request) BUT i can imagine that the device won’t accept ALL data when moving sliders.
I noticed that if I do slow and little changes the second request is mostly ok, any fast changes causes the second dump to have a smaller value then the one on the screen (like only part of the slider movement was recorded by the device).
If i were you i’d verify that with some audible results, that is something you can hear when changing a specific parameter (like tuning of one operator or the overall level of it). So that you can verify that you slider movement changed the parameter to the value on the screen.
I often got “SYX ERROR” on my DX21 the TX7 doesn’t display that message.
I tried changing the p.w range (pitch wheel) and it works fine both panel->device, device->panel (when dumping). Don’t know if the voice data is the same (i don’t think you can access the voice parameters on the crappy LCD of the TX7?)
What i would try too is setting some parameters on the panel, and writing those settings on the device as a program and then dumping all voice data for comparison. Maybe it’s the edit buffer that doesn’t have to correct value maybe it’s somewhere else in the device memory and it needs to be flushed somehow ??? just a thought.
A few things I’m finding:
The “detune” function does not seem to send/receive properly in the newest version. All the patches show me a value of +7 on the detune for each operator. If I lower them all to 0 (or any value) and then hit the “receive parameters” button the value returns to 7 in the panel. I haven’t tested the instrument with a tuner, but my suspicion is that all the operators for the patch I was working on last night had a value of 0, but the panel wasn’t sending/receiving any correct data for that parameter at all.
I’m also having the “click the receive parameters button twice and get change in settings” bug.
The receive performance parameters button is not grabbing all the correct data either. I can test that more specifically over the weekend, but basically nothing updates in the panel for me.
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.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.
It appears to be very solid and stable right now. I think the Performance mode is working better/correctly too. At least so far.
The program slider doesn’t seem to do anything. It doesn’t react to the device and it doesn’t change what program I’m on.
Feature request: Rename the patch?
@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…
No worries at all. I can deal with names that don’t make any sense in the meantime. Ultimately I’m hoping to create 32 unique patches and load them all in for my own uses and then simply be done with programming this thing. I’m learning a lot of interesting stuff digging with the FM world.
I did notice another bug though, the Porta Mode data is displayed the opposite from the function sent to the device. So if your thing says Follow it’s really in Retain mode and visa versa. It is consistent with grabbing and sending the data, the display in the Panel editor is just the opposite.
- The forum ‘Panels, Components, Macros’ is closed to new topics and replies.