Help For SysEx ReMapping And Interrogation For Lexicon PCM80 Remote?

Question

MIDI Target Manufacturer(s): Other/Unlisted Maker

OK, so after reading the Mididesigner March, 15 2022 blog post on SysEx here:

https://mididesigner.com/sysex/
I wonder if I can get some help with my plans to make a
MDP2 remote for Lexicon PCM80/81?

The issue with the PCM80/81 is the parameters' IDs are different
for every algorithm; there are 43 algorithms in total;
I will just start with the 10 native PCM80 algos.

Ideally, the remote would be able to chase algorithm loads;
then> automatically open an image of the current algo diagram in MDP2;

the diagrams are full screen MDP2 except the MDP2 header nav elements
MDP2 buttons on the the image to open/close hidden panels of parameter controls.

More info for context:
I've got the named ticks already done;
6 diagrams of 4voice algos made- so my design format is established

My plan at this stage is to use a lot of hidden panels on One Big Page
because the split page is detrimental to my image diagrams.

A clone of the display would be nice, too.
The PCM8x hardware display does not chase
and I can see the display clone idea possibly being moot.

Bandwidth could be limited if calls to the hardware  
by the remote only request parameter sync
once a hidden parameter panel is called
rather than request a Bulk Dump on algo sync.

I'm assuming massive stacks of hidden panels to be
a cumbersome stumbling block for building layouts.

50+ images are probably going to make it very heavy;
I could conceivably make 3 different remotes to lighten the load;
one for PCM80 native, on for PitchFX and one for DualFX.
I would certainly start with PCM80 native only and test how heavy
just that one is.

Any help with StreamByter coding greatly appreciated

Thanks,

_todd

Answer 1

A few thoughts -

Sanity ends after about 6 or 7 stacked show/hide panels. 

•  Working with stacked show/hide requires a deliberate approach.  Lock everything except panels, completely unstack, reverse locks, do your editing, reverse locks, restack.  
• You need room to unstack everything, so a theoretical upper limit would be 47, one page for the stack, 47 empty for unstacking.  Then that layout is effectively full.  (Edit - if you are very careful, you might get away with a single extra page to unstack.  But sometime you will lose a control in the stack, then you will have to unstack and check every page to see where it ended up.)

In my RD2000 layouts, I used the stacked panels only for program delay only, which had five different algorithms.  The most I have stacked is 10 in the Jupiter X(m) manager. 

The RD 2000 has more than 60 different effects, all with different encoding.  I used separate pages for different effects, and did not encode them all.  I focused on either the most useful and ones with the most settings.

To help, I ended up with a big matrix of memory locations vs parameters.  Then I could find which effects shared settings, allowing either a COPY or a MAKE SIMILAR (with a different label).

Each page has a separate LOAD button, so only parameters applicable to that page are requested.

Getting the first page up and working can seem daunting.  Once you get over that hurdle, it is just making license plates to get the remainder going.

Images

RD2000 Mfx Parameter Matrix.png

Comments

Thanks for the quick response :-D

can MDP2 verify currently loaded algorithm automatically? Employment of a LOAD button is something I'd like to avoid. Maybe a sync/re-sync button...(which is essentially the same thing)

Why worry about it being ASCII? Just use the SysEx, no? The PROGRAM or REGISTER NAME isn't really needed here...nor the ADJUST KNOB assignment name...just the Algorithm to load corresponding panel. I'm sure other issues will crop up in development. (btw: on PCM8x/9x PROGRAMs are ROM and REGISTERs are RAM (user presets)...there are 50 REGISTER memory locations)

PCM80 native algorithms are not the only ones. There are the PitchFX and DualFX algorithms to be concerned with as well, which are PCMCIA expansion cards. PCM81 is a PCM80 with PitchFX native in the unit; therefore a PCM81 with a DualFX card installed has all the algos. PCM80 and PCM81 do have different MODEL IDs in SysEx header.

Typically, PCM8x users would use a MIDI footcontroller for PC...or front panel manual loads... my remote layout does not need to be a PC control. Further, the two main issues with the PCM80, 81, 90 and 91 are menu diving UI and having to consult the algorithm diagrams and those are the main reasons for need of this remote layout. I'd rather include remote front panel controls than PC management in the remote layout.

Further, I have come up with another idea for a remote display mainly because the PCM8x display doesn't chase anyway, thus user input at the remote control could drive pseudo display with a midi listening...

---

Re: automatic verification.  SB can send a query every xx seconds, but this doesn't work in MDP2.  Instead, you can use an old dsabou hack to send a periodic query.  I rely on LOAD buttons in most of my layouts without issue.

Re: worry about it being ASCII - the ASCII IS the SysEx.

The text matching code was easier than I thought, only ~ 18 SB lines to read a table looking for a text match.  Big thing is loading the text array to match, but that can be automated in a spreadsheet.

So we can:
- read an inbound SysEx for a text string,
- see if that matches a stored text string, and
- take action in MD based on the matched string, such as jumping to a specific page.

I still plan to noodle around with the hash approach.  If the hash works, we don't need the a-priori knowledge (loading the array of potential names for match).

I expect to have the example posted in the next few days.

I am still surprised that the SysEx report doesn't include the program change number or slot number.  But then we wouldn't have this interesting coding challenge.

---

Re: "I rely on LOAD buttons in most of my layouts without issue."
I don't see how LOAD buttons can work in this case. User will have to have to know which algo is loaded and that's not easy to see/ identify without defeating the purpose of the remote. I can see a need to re-sync once the correct page/layer is loaded. I mean, really, the best way to have this work for end users is a separate layout per algo, because if the user selects a different page while using the remote- going back to that page could be really confusing and some messy, speaker/ ear breakers could happen pretty easily.

"Re: worry about it being ASCII - the ASCII IS the SysEx."
Understood...it's just that you said text...I do understand what's going on there :-)

"The text matching code was easier than I thought, only ~ 18 SB lines to read a table looking for a text match.  Big thing is loading the text array to match, but that can be automated in a spreadsheet."
...couldn't these algo text strings be ALIAS in SB code? I suppose that might bloat it even more...

"So we can:
- read an inbound SysEx for a text string,
- see if that matches a stored text string, and
- take action in MD based on the matched string, such as jumping to a specific page.

I still plan to noodle around with the hash approach.  If the hash works, we don't need the a-priori knowledge (loading the array of potential names for match).

I expect to have the example posted in the next few days."

That's fantastic, thanks so much...I look forward to what you come up with. Do you need a list of all the algos from me? There is a different Midi Implementation Details doc for every set of algos if you feel the need to look at that...the algos are numbered, but IIRC the SysEx dump with the Algos numbered is pretty large.

"I am still surprised that the SysEx report doesn't include the program change number or slot number.  But then we wouldn't have this interesting coding challenge."
Well it depends on the info that is requested from the PCM; there are many different kinds of dumps. I chose the Effect Information dump because it is only 45 bytes. A SINGLE EFFECT dump has 882 bytes and doesn't report back the algo.

This is just the first challenge....figuring out how to build the part of a remote for PCMs' PATCHING is potentially a hefty challenge....and probably the most cumbersome part of the PCMs' UI; therefore, a known want for users.

Thanks so much!
_todd

---

I posted an example layout that reads text in a SysEx message and takes action based on a text match.

---

wonderful! I look forward to investigate and employ it

Answer 2

A few thoughts -

Sanity ends after about 6 or 7 stacked show/hide panels. 

•  Working with stacked show/hide requires a deliberate approach.  Lock everything except panels, completely unstack, reverse locks, do your editing, reverse locks, restack.  
• You need room to unstack everything, so a theoretical upper limit would be 47, one page for the stack, 47 empty for unstacking.  Then that layout is effectively full.  (Edit - if you are very careful, you might get away with a single extra page to unstack.  But sometime you will lose a control in the stack, then you will have to unstack and check every page to see where it ended up.)

In my RD2000 layouts, I used the stacked panels only for program delay only, which had five different algorithms.  The most I have stacked is 10 in the Jupiter X(m) manager. 

The RD 2000 has more than 60 different effects, all with different encoding.  I used separate pages for different effects, and did not encode them all.  I focused on either the most useful and ones with the most settings.

To help, I ended up with a big matrix of memory locations vs parameters.  Then I could find which effects shared settings, allowing either a COPY or a MAKE SIMILAR (with a different label).

Each page has a separate LOAD button, so only parameters applicable to that page are requested.

Getting the first page up and working can seem daunting.  Once you get over that hurdle, it is just making license plates to get the remainder going.

Images

RD2000 Mfx Parameter Matrix.png