Implement banks for performances

[probonopd]

With #500, "only" 127 performances can be handled (note that the TX802 could handle even fewer!).

In order to be able to have more than 127 performances, we need banks, like we have for voices.

Reference:

• Add Program/TG Select buttons and choice for Program Change to act on Voices or Performances #500 (comment)

[diyelectromusic]

Just to be clear, the number of performances supported is set by:

MiniDexed/src/performanceconfig.h

Line 31 in 375900b

#define NUM_PERFORMANCES 256

at 256 and the UI and up/down buttons (if used) can support that fine. It is just that only the first 128 are selectable via Program Change messages over MIDI unless we implement some kind of idea of banks.

Kevin

[probonopd]

I am interested in MIDI Control Change (CC) Program Change messages for setting LSB and MSB.

[Banana71]

My thoughts on this topic as a suggestion:

In the basic version, the miniDexed is operated with an encoder. In my opinion you should limit the number of Performances in a bank to 64, with 128 Performances you quickly to get dizzy.

Overall, I think the limit to 256 performance makes sense. This results in 4 banks of 64 Performances. Whereby once the structure for the program is in place, 8 banks would certainly not be a problem.
How I imagine the operation: From the UI in the Performance Load menu, the performance can be selected as usual. The bank is displayed in the top line and can be changed by pressing and turning at the same time. (A,B,C,D,...)
Switching via MIDI program change would be like with the Voices.

How could you manage the performances on the SD card? In the Performance folder are all the Performances in ascending order from 1-256 (512) and the rest is done by the software.
Or you create 4 or 8 subfolders according to the banks (A, B, C, D...) . Probably much more complicated to program.

That's just my thoughts on the discussion.

[probonopd]

Personally, I don't like artificial limits. Unlike with real hardware synths from the 90s where bytes were precious, we have gigabytes of them on the SD card. So if someone wants to have 127 banks with 127 performances each, why not let them enjoy their 16,129 performances ;-)

For the same reason I think we should not be loading everything at boot time, but read the files only when the data is needed. E.g., if someone requests bank 127, performance 127, the file 16128 should be read into memory. (The same goes for voices.)
This way, we would also get rid of the annoying long boot time (where we are currently reading all voices and performances for imho no good reason).

[Banana71]

I thought again about the handling of performances.
If it has to somehow fit into the Yamaha concept, we probably can't avoid the sysex format.

For discussion:
A Performances.syx (Perf.Bank) contains the data of 128 performances. The performance name is saved in Performance.syx.

What should be considered: The performance bank must be selectable. When saving a performance, the storage location must first be selected in Performance.syx.
You need a copy function to manage individual performances in Performance.syx or across Perf.Bank.
Maybe you should leave a few bytes of space in each TG as a reserve.
Optional: An editor for performances that supports the performance.syx format.
Performance Sysex.ods

[diyelectromusic]

One of the reasons I think we need to rethink this is because at present performance data also includes bank/voice numbers and MIDI channels, which make no sense as part of a "performance voice" - see #454 (reply in thread)

Fundamentally, I think performances need rethinking from the bottom up. But maybe a performance.syx would be a way to do that, leaving the old performance.ini setup for legacy reasons...

But a key decision is: should voices be part of the performance, or should the performance specific the bank/voice number to be used? I know it is nice for it to be "self contained" but it also means that the voices used as part of the performance aren't available independently either unless already one of the existing ROM sets which is a shame.

In my ideal world, performance.ini should specific some basic parameters about the setup (inc bank/voice/MIDI ch), but performance data representing an "eight-TG voice" should be a different format - the performance.syx.

Also in my ideal world, loading, editing and saving voices would work in essentially the same way as loading, editing and saving performances so the "mental model" required is the same. But we don't allow editing AND saving of voices at the moment, other than part of a performance, which needs sorting out too...

Kevin

[Banana71]

I corrected the image in my last post, I had forgotten the parameters for the effects

One of the reasons I think we need to rethink this is because at present performance data also includes bank/voice numbers and MIDI channels, which make no sense as part of a "performance voice"

bank/voice number is unnecessary, I agree with you, but the MIDI channel must remain adjustable for each TG.

But a key decision is: should voices be part of the performance, or should the performance specific the bank/voice number to be used? I know it is nice for it to be "self contained" but it also means that the voices used as part of the performance aren't available independently either unless already one of the existing ROM sets which is a shame.

If the performance only points to the bank/voice and does not contain its own voice data, it is imperative that everyone who uses a performance also has the same Voice.syx in the same order on their SD card. I see big problems there.
Rather, it would have to be the case that every voice in a performance can be saved directly in a Voice.syx.

In my ideal world, performance.ini should specific some basic parameters about the setup (inc bank/voice/MIDI ch), but performance data representing an "eight-TG voice" should be a different format - the performance.syx.

My worldview looks different :-).

[BobanSpasic]

First, do not use that SysEx header, please. All the voice editing software out there will go nuts.
There is a Yamaha Universal Dump format, with ID of $7E and sub-IDs in text form. Just take the sub-ID of "LM PMDX" or something like that (it should be 10 characters long. LM followed by two spaces is a standard, 6 characters are free to decide).
Voice Data could also be in VMEM format, to save some space.
Parameters with negative and positive values need an extra byte for the sign if the parameter already takes 7 bits (e.g. Detune).

Having the voice data out of the performance will do some damage on portability of the performances files.

Take at least 20 bytes as reserve, for future parameters. There are things that are very easy to implement, like velocity layers - here you need 2 parameters per TG.

btw. I did prepare the whole specification long time a go, but nobody was interested. In the fact, I've already had it implemented in MiniDexed Control Center.

[Banana71]

I have implemented your @BobanSpasic objections accordingly and edited them above. Is NoteShift only 1 byte long?

I did prepare the whole specification long time a go, but nobody was interested. In the fact, I've already had it implemented in MiniDexed Control Center.

You were probably way ahead of our time, 🤷‍♂️🕵️

[BobanSpasic]

F0 43 2n - about that 2n:
n is the MIDI channel, zero based.
Parameter s (2 in the example above) can have the following 3 values:
s=0 - voice/supplement/performance dump <-- this is what we need
s=1 - direct single parameter change
s=2 - dump request

About the MIDI channel - we need some kind of Master MIDI channel for the whole device. The device should receive the performance SysEx over MIDI just if this Master MIDI channel is the same as the one from the dump.
This is needed if you have more than one MiniDexeds chained on the same MIDI line (over MIDI Thru).
It has nothing to do with the MIDI channels in the performances. The Master MIDI channel is just relevant for receiving performances over MIDI.

About the NoteShift parameter, we could translate it as 0-48 in SysEx for the -24 to 24 in the INI file. This is also how the Yamaha does it. This way it remains one byte.

[BobanSpasic]

@Banana71 isn't Voice Data 155 bytes long?
There is a CC with number 156, but it isn't included in dumps/SysEx.
btw. it is a good chance to add one more parameter (even in performance.ini files) - Operator On/Off (bit-wise), just like that CC 156.

[Banana71]

We have the variable PerformanceSelectChannel=x in minidexed.ini. In my opinion you could equate it with the MidiMasterChannel. Or do we need an independent variable?

isn't Voice Data 155 bytes long?

The length of the VoiceData of 156 bytes was taken from the Wiki. When editing, switching off individual operators could be helpful.

[Banana71]

We have now reached a point where the next step is groundbreaking and should be carefully considered. I assume that the implementation is difficult and time-consuming. At the moment the problem and the solution are being discussed together. Wouldn't it be better to first describe exactly what we want to achieve (set goals) and then look for the solution.

What would a keyboard player expect from the miniDexed when dealing with Voices, Banks and Performances?

• The sound patches of each TG in a performance can be loaded or saved via the existing structure (sysex/voice/000001_name.syx).
• Patches and banks can be received and sent via MIDI dump.
• Editing patches using an external editor (e.g. Dexed)
• Performances can be loaded, saved and copied. The storage space can be freely selected (number in a bank).
• Each Performance should work independently of the Voices present on the microSD.
• A TG or groups of TGs can be copied into an existing Performance (Load TG from Performance XYZ). *)
• Performances can be received and sent via MIDI dump.
• Program change via MIDI: the way it already works
• Some global settings should be adjustable via the UI: MIDIThru, MIDIRXProgramChange, PerformanceSelectChannel, ChannelsSwapped, EngineType, MasterTune

Limits and rules: what exactly and how much of everything?

• Voices: All sound banks from the /sysex/voice/... directory are loaded. The voices are in Sysex format.

• Performances: The number of performances should depend on the usability of the UI. That's why, in my opinion, there should be a maximum of 128 performances in a performance bank. (Optimally 64).

• Only one performance bank is loaded at a time.

• Performances are organized in a Performance Bank.

• The Performance Bank is organized in the Performance.syx file.

• The Performance Bank can be loaded and saved via the UI.

• The storage space of a performance can be freely chosen. (Performance Bank and Performance Number)

• A performance dump via MIDI should be sent and received. (Would transfers from performance banks via MIDI be practical?, or would it be better to wait until Circle has access to the SD card via USB)

*) On miniDexed or in an editor

see also #571 here

Each MiniDexed is built individually and the requirements and expectations are probably just as different. You definitely won't do justice to everyone. I'm happy with how it works now, but there's still a lot of potential.

[Banana71]

I don't see any data compatibility from Performance.syx to other devices. With the performance banks, as @BobanSpasic already said, we should take the TX-802 as a example, additionally with the voice data and effects parameters.

[BobanSpasic]

@Banana71 - if I understood your previous post correctly, you want to have more than one performance in one SysEx file?
We will get some 1,4kB in size for one performance. If we go for banks of 64 performances - we are at some 90kB in size.
Sending 90kB over MIDI works fine if you do not have many cables near the MIDI cables (incl. audio and power supply), but if you are on stage or somewhere else surrounded by electric noise, it can be a painful experience to transfer the bank.
I know it is a corner-case, but we should have it on our mind. Implementing checksum for transfers here would be a necessity.

About TX802 performance files - these are also huge, some 11kB because these are not real binary files, but an ASCII text describing binary data. They are just like our voice data inside the performance. ini files.

[Banana71]

I know it is a corner-case, but we should have it on our mind.

This is really a very dark corner :-)
Just hope that it works and only the bravest ones do a MIDI dump on stage, but we should have it on our mind.

• A performance dump via MIDI should be sent and received. (Would transfers from performance banks via MIDI be practical?, or would it be better to wait until Circle has access to the SD card via USB)

[probonopd]

...and the elephant in the room:

We want something to edit and play performances on a host PC (i.e., a Dexed derivative that can handle our performances) and can send them back and forth to the device.

[diyelectromusic]

I think this can probably be closed now due to #581

Kevin

[diyelectromusic]

I think this can probably be closed now due to #581

Kevin

Can we close this one now?