Nice. Glad you got that started. By taking small steps, it’s clear what is working and what is not.
I’d hate to waste time creating a bunch of controls and labels and such only to find out i can’t send data back to the device (or whatever)
1 Like
Ah, will try this tomorrow. Observing your caveats, and I think I dl’d 2.14 a couple minutes after publication.
In tc2290_notes.txt sent as part of the first zip file you wrote “remember to push front panel MIDI enable set Special #2, #3 to 0 - check Special #110 for ID (set to 0 for now)” - is it 110 or 116? In the Spec # list on the 2290.com website it shows “110 0-127 0 Global 27- Device number” and " 116 0-1 0 Global 30- Disable keycodes on slave: 0 = Off 1 = disabled"
I haven’t posted an updated notes file yet.
Originally I thought I needed to have specials 110, 111, 112 set a certain way to get a patch to transfer. That is not necessary (given I can retrieve any number patch no matter what those values are).
Special 110 could be important in the future if the 2290 is looking at it when full patch dump data is sent to it. Leave it set to 0 for now.
Special 116 set to 0 simply turns off the constant keycode sysex strings sent by the 2290.
For fun, if you have the 2290 + Electra One hooked up and the E1 console app running (or MIDI-Ox), set Special 116 to 1 and press some front panel buttons and look at the log file. Streams of sysex messages indicating a button pushed, held, and released.
I was wondering why Console showed no Preset (on Preset Tab, next to sliders-icon, top far right). I learned the Load Preset button on Console seems to do two things (at least): 1) loads Preset into E1 and 2) loads the Preset into Console. At that point, Console shows the name of the preset, and if it is working sort-of, each Page (of the preset, in Console) shows whatever’s there in the Preset.
Well, loading any of the first Presets you posted (w only the Patch on page 12) shows it “loaded” in Console. Oddlly, when Loading the most recent Preset (w Patch on page 12 and 4 buttons on page 1), Console shows “no preset”. This is the case even though the Patch Request button seems to do something. But perhaps if Console for some reason will not accept or recognize the epr file, then maybe it will not log anything either. And: if Console is not “power-cycled” after having used it to load one of the first epr-files, then I cannot tell that Console doesn’t accept or load the latest version (from Dec 7 I think), because the Preset Tab in Console still shows the same Preset name (Preset tab in Console, top right).
Thus: the latest epr is easy to load into Electra, but Console will not touch it (or be touched by it). It would be easier for this novice to keep up if each iteration of the epr gets a new version number - not only in its file name, but even inside the file, so Console also shows that version number. I hope that’s easy to understand and easy to do…
Since I’ve never used the Load Preset button on the console app I will have to play around with it to see what you are saying and determine what to do next. I always work from the web app and if I need debugging help, I’ll bring up the console. I have not had any issues with the print statements showing up in the Console except when the LUA code is corrupted or I typed in some syntax error. In those cases I’ll get a message about no response found or something like that.
I used the Console now because I assumed it would report what came from TC2290 but it didn’t. “Load preset” (Preset tab in Console) works however, sort of just another way to get the Preset into E1, but also to have it available in Console. Still haven’t seen anything like the amount of info that Console shows when power-cycling the E1.
Second day: I reached your third bullet point by now.
I have been documenting what I did so far on the KingKorg. That was a good tip!
-
Found the full midi sysex implementation
-
Succeeded via MIDI OX to
- request and receive current patch dump
- request and receive and patch dump via its program number
- perform a parameter change (cutoff frequency) from Midi-ox to King Korg
- receive sysex parameter changes back from King Korg
Some observations:
- allthough documentation stated any parameter change would be followed by ACK, NACK or FORMAT ERROR, those ACK or NACK I’ve not seen.
- The parameters changes the King Korg was supposed to transmit, weren’t there originally. I still got CC-parameters coming through. It suddenly changed into parameter changes, not sure what triggered this. Is that standard behaviour?
I’ve been able to import your epr file and load the LUA script in it. First time (again). If I read well, the fader is supposed to trigger function setProg, using the fader value (1-99) as input?
Never been reading LUA in my life, so let’s see if I can understand your script:
- ProgNum is intialized on 1, then takes over the fader value?
- Patch.onRequest sends out “F0 33 00 03 progNum F7” to Port 1 of the E1? Am I correct the function doesn’t do anything with the input ‘Device’?
- If suppose patch.Onresponse interpretes the incoming answer. Where do I find the info on these functions ?
- this deSyx is an array? parsing the answer sysexBlock into ‘blocks’? One block = 1 byte?
- I see you then print deSyx[6]. That will be a typical TC 2290 interpretation of the 7th byte?
- updPatchNum is just printing the value of the 6th byte?
- for the Delaytime it looks like you are performing some hex magic. Can you refer me to a good reference to learn this language?
Sorry, lots of questions, but I’m a rookie (and an old one) on scripting
Some quick answers – anything in the LUA section of a preset is documented in either Martin’s Electra One documentation (such as patch.onRequest(), patch.onResponse() or in generic LUA programming documents. If you google ‘LUA programming’ you’ll get enough references to understand the basic syntax.
Yes - deSyx is an array. Predefined as empty {} and then filled up with the reads from the buffer.
LUA numbers arrays starting with 1 not 0, so without any extra processing on the data array[6] is the 6th byte
I wrote a couple small functions to take multiple pieces of data and create a larger thing from it. The tc 2290 sysex breaks all data into 2 (or 4) bytes. They do this because some values are larger than 127 (or 0x7F) which is the largest number you can legally pass as a single byte inside a sysex message.
So the basic math uses & to “mask off” the stuff you don’t care about (or looking another way - isolates the bits you care about). Martin wrote up some post earlier on this forum about hex math and such, but the basics you need here are this:
8 bits in a byte. If you look at math tables/format conversions you’ll see how 0x0F means the lower 4 bits are being looked at (in this context). << means shift those bits some number of positions to the left. | means use the bits from both sides to make a larger expression.
This is all a high-level generic description. Read some math/programming texts to learn about “bit masking” “bit shifting” “logic operations”
updPatchNum() is just printing the patch number to the console log for now. I might incorporate that into a display for user reference or I might just delete it in the end. But it was useful to show I was grabbing what I thought I asked for (versus a hardcoded patch number or being ‘off by 1’)
2 Likes
You got me started. I got the basic Sysex parameter change from E1 to the synth working now, and found the Lua docs as well as Martin’s LUA extensions. Will be studying and experimenten for a while now. Thanks for getting me on the way.
1 Like
Glad you found it helpful. The back-and-forth dialog also helps illuminate areas that I thought were clear but really needed an additional layer of explanation.
1 Like
Trying to get by with less than a full deck, so I borrow yours again…
In a Preset with controls type Virtual, do such Presets always use LUA or some other scripting variant?
I didn’t think that Virtual controls automatically sent any MIDI values, so you’d have to use something else (like a LUA function) to have it do something useful.
Martin can explain the intent behind Virtual as well as give some possible use cases. I’m just one of the users of this system, so I don’t have any particular insights others than what is gleaned through trial and error.
Will try what I wrote a little later this evening.
So it’s all a bit opaque but some things are logical. I found a microWave Preset in the forum and it’s way more advanced than the one in the public library. Nearly every parameter controller in Electra is handled by LUA - which I discovered by copying the LUA script that was included with that download and pasting it into the correct field in the Preset. Intense being able to get into the brain of the microWave again after all these years. It’s not a complete parameter set but very nearly.
So there are some easy things that can be done, that I discover I can do, like copying parameters from one Preset to another, pasting scripts (or probably even script snippets). I think I read Martin commenting on someone’s question about making it very evident that a Preset requires a LUA script to work at all (coming soon I imagine) and if LUA’s included (like in the TC2290 stuff you put up) then put that script in the Preset and lots happens. Same caveat I hope for Patch Request capability, ie a Preset that has it should show it (like PR in the name).
Very much appreciate your efforts with the TC so far!
Thanks. Glad these in depth discussions are helpful.
I spent a few minutes trying to update tc 2290 values from the Electra One. It works, but with lots of issues. I started with a simple fader sending “up arrow” and “down arrow” keycode sysex strings, but the E1 sent them too fast and there were issues trying to use an encoder to scroll from 1 to 32,767.
Still looking at the best way to send a new value back to the 2290.
fyi I found the ‘data types’ chapter on the wiki page about the json format very helpful. Once I got that , it became a lot easier to ‘read’ the Electra Preset Format Description.
Important perhaps to add: nearly all I can offer - for instance in the TC-effort - is to demonstrate what an end-user w/ no programming skills will experience using the Preset.
On “Virtual” - I read through the LUA-scripts for the microWave and Matrix 6 (works on M1000 as well) Presets I mentioned. Each of these scripts contains the term “Virtual” (in a context I don’t understand), but only 2-3 times in each script, while the Presets themselves have several pages of controls w/ type “Virtual”. So the Presets do nearly nothing without the LUA script (duh), while for instance a controller for Program Change (type Program Change) worked without the script (also duh, I assume). Getting there, at a snail’s pace…
Lastly: mioXL/Auracle is still at times a stumbling block but evidently worth the effort.
@Resyn
I happen to have a MioXL as well. For now I’ve taken it out of the loop when controlling a hardware synth via the E1 to ensure it’s not causing any undesirable side effect. My Matrix 1000 is version 1.20 from Tauntek. So, if you have anything not going well you suspect is caused by the MioXL and/or the M1000, I may try to reproduce it.
No the mioXL is cooperating - there was a hint from Martin at one point that something in Auracle was mixing things up but I got the impression it has been worked out in iConn firmware. I have a 1.20 (M1K) as well, and I think I haven’t discovered anything that does not work in the M6-preset I found a few days ago. Haven’t really had time to compare it (I think from akira?) with the one in the public batch, they differ a little but neither seems obviously better than the other. Perhaps akira’s is snappier - haven’t even had time to check whether the public one uses LUA at all…
The mio doesn’t seem to interfere as far as I can tell, not here anyway. But the main thing is getting my head completely around all the mioXL offers, and I’m in the process of changing the whole MIDI installation here since the mioXL clearly offers much more than the Unitor and amt8’s I had been using. Have just bought 2 more of them and that will cover everything that can conceivably be controlled by the Electra, the rest can be connected to the extra 4 DIN outs on each mio or possibly a string of Unitors could be hosted by a mio (or two).