the direct USB connection between E1 and PC is solely used for editing presets.
all MIDI-traffic to and from the E1 is done via port 1 DIN MIDI into the MioXL MIDI router
that router is connected to the rest of the gear but also to the PC via RTP MIDI 1 and 2.
The Electra 1 (connected to MioXL DIN MIDI 2 here) routes its info not only to the synths and the second and third MioXL (via RTP Midi 9, and eventually 11), but also but to the PC on RTP Midi 2.
In other words: while the synths and the E1 are talking to each other, they also sent the same info to the synth for Midix-Ox to witness. But as this happens on a different port than the E1 programming port, I circumvent the lack of âmulti-clientâ mode a PC has.
Yeah Mac users have had the multi client driver support for a while now, not just for midi but for audio with the aggregate something something (Iâm on windows, obviously) that lets one combine soundcards into one mega-card as seen from the application using the driver. Luckily my soundcard has more I/o than Iâll ever need⌠But also forces me to stick to windows
My Motu midi XT can only rename itâs I/o on macâs, another stupid windows USB limitation. Honestly a big inspiration for swapping it for a mioxl, along with all the usb-host capabilities.
Eager to see what CME comes up with their 19" interface under planning. I have a bunch of their u6 pro, and they are super flexible, good drivers and very low cost.
Via USB , you mean? Iâm no longer USB to PC connections on the Mio but RTP-Midi: the Mioâs interconnect as well when the PC is down (my PC not always turned on when making music).
But I do recall when I used USB it did show as multiple MIDI devices in my DAW too.
Thatâs good news. The good thing: Iâm using themxfor many years now and it has a certain stability so what the underlying capabilities are, I already forgot
I found that the listening function has a hard time to detect the right SysEX question and Response if they contain variables. Add the variables only at the end.
What I would propose: keep both questio sysex and reply header hardcoded (as in your example), check that the synth does respond, and now make sure via the listening function in the E1 editor, you see the reply coming in, ready to be parsed.
You then choose a patch for which you set up at least 3 parameters on 3 different values, known to you (for instance put VCO1 level on 3, VCO2 on 6 and Noise level on 9).
Then request that patch and in the webeditor check for yourself if you find those 3 values on the places you expect.
I managed to find changes with three parameters so far using the Sysex Librarian⌠Will now try to see how to proceed with the receiving and sorting in the E One.
Trying to wade back into programming the Electra One mk.II (hereafter referred to as the EO2) by modifying a preset that I created some time ago for the Emu Morpheus.
Iâm new to the âPatchâ menu in the web editor - my LUA skills are non-existent, it scares me and also I canât seem to get it to show/receive any dumps from the Morpheus, even though I can capture the same dumps on the EO2 hardware at the same time.
I want to add patch parsing so that I can synchronise the EO2 Morpheus preset control values with the sound preset currently selected on the Morpheus.
Emu Morpheus responds to individual patch dump requests, however you have to tell it which patch number - it doesnât seem to support just dumping its edit buffer, so no ârequest current presetâ option.
However, the way Morpheus responds to parameter requests does relate to the edit buffer - tell it what parm address and it will return a parameter message with the current value in the buffer.
The most practical approach to parsing seems like it would be to just have a momentary button control on the EO2 fire off a shed load of parameter requests for all the parameters supported by the EO2 Morpheus preset, then update the EO2 control values with the received values. Am I right or is this crazy talk?
If I am right, what would this look like in the context of your tutorial, as it doesnât seem to cover this parsing strategy?
In some cases, it is not bad indeed to retrieve the patch via its patch number and not from the memory buffer. On a Blofeld f.i. when you change a patch and immediately thereafter you request the memory buffer, so sometime end up with the previous patch that is still in memory.
One of the way I resolve what youy just bescribe is by adding a patch request concept in your E1. Youâll find it in most of my presets in a page called âMAINâ or âPERFORMANCEâ, on the lowest line.After you tweak that lua-function for your synth (typically called ârequestItâ or âpatchSelectâ) , add in it after the program change the sendSysex command to request the dump of the patch you look for.
Thanks for this, using a program change could work, although Morpheus decouples PC messages from actual patch numbers by having a âprogram mappingâ feature, which makes things a bit weird.
However, Iâm interested to know what you think of my other idea - using parameter requests triggered from a âsyncâ button? That way I donât have to worry about programs at all, I just sync parameters with the edit buffer.
Probably there would be about 200 parameters in the EO2 preset for the Morpheus, so it would need to send individual parameter requests for them all and receive the responses without choking.
However the Morpheus UART seems pretty strong - the manual talks about setting the MIDI buffer delay to prevent the host computer from bogging down from the traffic, not the Morpheus itself.
You could do that through some clever set up in lua, so a click on a button would fire a for -loop going through all parameters and firing a sendSysex for each of them. Then , again in lua youâll have to set up your onSysex callback, and tell the script how to identiy itâs a response your were waiting for, and for those that are expecting tell the script where to find the sysex param address, where to find the sysex value and store them in the rightly mapped E1 parameter and mapped E1 value.
I believe you about needing to use LUA. However, this also requires me to understand LUA whilst also not being a member of that rare fraternity - the âDeveloper-Musicianâ.
For my intended purpose, I need my EO2 preset to iterate through all the sysex parameters I have set up within the preset, and for each one:
Look at a specific ls-ms byte pair (i.e., the parm address) within each sysex parameter.
Encapsulate that byte pair within a parameter request message.
Send the parameter request message to the Morpheus.
Receive the corresponding parameter response message and store it in an array.
Find the parameter value ms-ls byte pair from within the response message in the array.
Match the parameter to the corresponding control within the preset.
Update the control value (remembering to correctly parse the ls-ms bytes into a format the EO2 preset control can understand).
Move on to the next parameter.
Stop when reaching the end of the parameters.
Iâve looked over the electra.one LUA tutorial, but itâs incomplete (sections missing) and doesnât cover what I need to know - itâs not use-case focused, i.e., on how to get LUA functions and Sysex to interact within a script, inside a preset, with the correct formatting & syntax.
Are you actually using the web app to write and test your LUA? Or a third-party tool? My options seem to be - lose myself inside a gigantic JSON script, or try to understand the GUI screens in the online editor, which seem cryptic.
For example - I canât figure out what the âControlsâ window is for. Listing all the controls and their attributes âspreadsheet-styleâ would make sense, but only if the fields are directly editable. Otherwise it seems a bit pointless.
But mainly itâs the âPatchâ window that confuses me the most. It has three tabs - âMessagesâ, âMappingâ, and âJSONâ. Basically this needs a full tutorial in its own right. I have so many questions - but this is not the place for them.
