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

jkhiser, thanks so much for your reply :-)

Indeed, confirmation of the difficulty of using stacked hidden panels is appreciated
a layer tree is sorely needed or something like it
In my planned scenario the image diagrams are full page (2 sides of MDP2)
I guess I better just give it a try and see how bad it gets

My typical way to make layouts is create a section of a couple pages with "widgets" of controls that have all the settings needed and just change ID targets

I've already made a huge spreadsheet showing parameter IDs in algos

I don't yet understand how SB interrogates a spreadsheet....I've read your posts about it....I just haven't tried jumping thru any hoops yet

---

There is no direct connection with SB and a spreadsheet.  I use the spreadsheet as part of my workflow to (1) organize and decode Mfx as above (2) keep track of which controls are on which page and auto-build the named ticks to LOAD (request) control settings from the hardware (3) create the named ticks to scale and display parameter values and MIDI values (4) automatically generate SB code to decode hardware bulk SysEx dump.

---

Ah, OK
thanks for clarifying; I look closely at your forum posts about what I need to do
I can see massive benefits to setting up excel to render SB code :-)

So, is there no way to get MDP2 to "automatically" open a target page or panel from a device Program Change?
I'll have to use a "LOAD" button? This would be am early first step to try and get working.

---

RE: So, is there no way to get MDP2 to "automatically" open a target page or panel from a device Program Change?
- I am not familiar with one, but it is also not something i have tried.  Will dig into it, but working on the current beta release is a higher priority now.

Re: I'll have to use a "LOAD" button? This would be am early first step to try and get working.
The LOAD buttons in my layouts are used to LOAD the current hardware settings onto the current page.


I'll have to use a "LOAD" button? This would be am early first step to try and get working.

---

Thanks! I have some ideas on how to achieve the "automatic" opening

re: LOAD button(s)
I did understand that as you describe

MDP2 beta? what's new? I'm looking forward to see

---

OK, so I've come up with something that should work using Stream Byter. I've realized that my first step is to determine which algorithm is currently running on the PCM8x by having SB send a SysEx Data Request message to a Lexicon PCM80 and then match a section of the Effect Information response from the PCM80 to an entry in an array. Once the match is determined, then I need SB to press a button in Midi Designer Pro 2 to open specific panels.

To get started, I just need to figure out how to write the SB rules to send the query to PCM8x;
AND match the section of bytes in the response to the MDP2 button presses.

I'm still working on learning SB, so any assistance greatly appreciated :-)

---

ok, maybe I should include some SysEx!

PCM81 Data Request for Effect Information for currently loaded effect:
F0 06 10 7F 7F 1A 7F 7F 00 00 00 F7

The response is a 45 byte message in which bytes 8 through 23 hold the Algorithm Name

Here is an example return:
F0 06 10 07 1A 7F 7F 51 75 61 64 3E 48 61 6C 6C 20 20 20 20 20 20 20 32 34 20 53 74 72 69 6E 67 20 20 20 38 76 61 20 4C 65 76 65 6C F7

thus, 51 75 61 64 3E 48 61 6C 6C 20 20 20 20 20 20 20 = Quad>Hall (ASCII)

---

We don't need SB to send the interrogation.  That SysEx just goes straight into a MDP2 control.

I am not sure I want to contemplate the horror of searching a text table for a match with SB - which is essentially assembly language.  It can be done, I prolly wrote code like that in the 70s or 80s, but there is a reason we have higher level languages now.  Practically, with the W array we could hold 2048/16 chars = 128 program names.  Looks like the PCM80 has 200 presets, so not enough memory.  We could work around by only matching on first 10 characters, but may not uniquely identify some presets.

But, we may be able to hash the ascii and just send a number to a MDP2 named ticks control with matching hash MIDI value.  Nice thing with this approach is that SB doesn't have to be updated when a program name changes.  If we are lucky, a 14 bit hash will be unique on the names.

Gotta do some traveling over the next week, but will be thinking through this while driving.  Like to get it coded in my head first anyway.

---

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