Thanks @diyelectromusic and @stevelittlefish

(This is a continuation of #271 and includes that PR, so only one of the two should be merged eventually.)

Hi everybody, I bring you my proposal to include control over the Portamento and Pitch bender parameters. This enhancement is necessary in order to play more expressive solos. Musicians will be grateful.

EDIT: The pinout in this post is outdated. See newer posts below for the recent one.

Continuation from here:

For maximum device compatibliity (including Raspberry Pi 1), we want to have a pinout that needs none of the extra pins introduced with the Raspberry Pi 2.

Since more and more people are building their hardware now, I'd like to propose the new default pinout rather sooner than later.

Should we ever use i2c for the display (easier cabling with fewer wires, potentiometer onboard but ~3 EUR more expensive), then we could even have room for SPI:

What do you think? Feedback appreciated.

Notes:

• 2.2k resistor betweeen LCD pin 1 (VSS) and LCD pin 3 (V0) (10k potentiometer would be better)
• Backlight enabled like this (note the balck and red short wires on the upper left of the green LCD board. K bridged to right side of C2, topmost right side pin of unpopulated chip footprint U3 bridged to the right side of the resistor. CAUTION: Don't blindly do this, measure with a multimeter and understand what you do first! No guarantees.)

MiniDexed_Pinout.zip

Raspberry Pi 1 seems to be nonfunctional since at least 2022-04-05: The last message is minidexed: Serial MIDI interface enabled, thereafter it seems frozen.

On 2022-02-28 it was definitely working: https://github.com/probonopd/MiniDexed/issues/12#issuecomment-1054505774

Raspberry Pi Zero continues to work, also in the latest builds. What gives?

Hi @probonopd , in order to complement the swichable Performance solution, I have added these additional features to improve the usability of the solution: -Custom defined new performance name: predefined Performance name can be modified. Characters are input by the rotary encoder, to move the cursor, hold down the encoder and turn right or left. Then just double click to confirm. -Delete Performance files: This allows to delete perfomance files from the list. To do that, just double click on the already loaded performance and confirm yes or no. The default performance.ini file in the root directory can't be deleted. -Change voice name: Edited voice can have a custom name (and will be saved on performance file). -Some minor improvements on related Methods.

Use this in combination with the latest Synth_Dexed (added a method called checkSystemExclusive()) which checks parameters, checksums, ... and returns a value for further actions).

This works for MicroDexed but I have no hardware for checking with MiniDexed.

SysEx master volume is currently not supported.

I'm using an RPi 3 (FAT32) with a USB MIDI controller, but it seems to freeze after about 5-10 seconds whether the controller is plugged in or not. It sounds great right up until then, though :)

Is there any way to do diagnostics/logging?

As an aside, I'm really happy to see someone working on this. I've been checking around for exactly this (headless dexed on RPi) every few months and was going to put in a feature request with dopefish to see if he would consider adding it to mt32-pi when i saw there was already a ticket for it. Then, I saw your comment about this project in the ticket comments! Exciting stuff.

https://yamahablackboxes.com/patches/dx7/factory/rom3a.syx

• 17=SAX BC
• 24=VOICES BC

https://yamahablackboxes.com/patches/dx7/factory/rom4a.syx

• 10=BRASS BC

https://yamahablackboxes.com/patches/dx7/vrc/vrc106a.syx

• 17=SYN.BRA. 4

https://yamahablackboxes.com/patches/dx7/vrc/vrc106b.syx

• 25=SYN.GUITAR

https://yamahablackboxes.com/patches/dx7/vrc/vrc108a.syx

• 15=Good-Vibes

https://yamahablackboxes.com/patches/dx7/vrc/vrc108b.syx

• 20=BCTrumpet

TODO: Test with other software instruments

Many USB keyboards can send Bank LSB and Bank MSB Changes, and Program Changes. If we put several .syx files on the microSD card, then we might use Bank LSB and Bank MSB Changes to select those .syx files, and Program Changes to select patches.

(Once #8 is implemented I can say which MIDI messages we need to react to.)

This PR modifies the following:

• Update submodule circle-stdlib to v15.12
  • System options can be defined cleaner using the "-o" option
  • Include KY-040 driver from Circle (removed from MiniDexed)
• Render sound on secondary CPU core 1
  • Enable multi-core support on Raspberry Pi 2-4
  • Does still work on the Raspberry Pi 1 with restrictions
  • Use CSoundBaseDevice::Write() instead overriding GetChunk()
  • CMiniDexed is not derived from the sound device classes any more
  • Add option SCREEN_DMA_BURST_LENGTH=1 to relieve bus congestion
• Add volume control to MIDI CC and UI

There is a new menu item in the UI, which controls the volume level.

The MIDI message dump and profiling should be disabled on the Raspberry Pi 1, otherwise one hears audio drops, when the screen scrolls.

Tested on RPi 1A+ (PWM, HDMI), 2B (PWM, I2S, HDMI) and 4B (PWM, I2S, HDMI). The UI has been tested with a RPi 1A+ only (because my hardware is connected there).

Hi, just wondering, what's the current plan on this? I'm willing to further reduce the size of MiniDexed and just limited with parallel LCD options... In particular, OLED 128x32 would be the best.

When you hit a note with high velocity while holding the Susatin Pedal and then pressing the same note a second time with low velocity then cuts off the first sound. That doesn't sound natural. Dexed doesn't behave like that. (And all other keyboard instruments I know)

Support MIDI Bank Slect for MSB and LSB Reload Preset of new bank when bank is changed Adding much more cartridges in the getsysex.sh script --> Only tested on RPI 4b

Should BankSelectLSB bounds-check the provided MIDI value and limit to the number of loaded banks? Similarly should ProgramChange limit to the number of voices per bank?

Alternatively should there be an option that if a ProgramChange message comes in over MIDI the values 0..127 map onto the first four banks of 32 voices each? i.e.: 0..31 -> bank 1 voices 1-32 32..63 -> bank 2 voices 1-32 64..95 -> bank 3 voices 1-32 96..127 -> bank 4 voices 1-32

Of course this means that a MIDI sequence: Set Bank=2; Set Program = 4 would end up selecting bank 1, program 4 (as programs 1-32 map onto bank 1)... so this probably has to be configurable...

When a ProgramChange is initiated (either over MIDI or via the UI) then the following happens:

• MiniDexed::ProgramChange is called
• which calls MidiDevice::SendSystemExclusiveVoice
• which calls MiniDexed::getSysExVoiceDump and then calls send() for each attached MIDI Device with the resulting data.

getSysExVoiceDump builds a Yamaha specific systems exclusive message that starts with the bytes: 0xF0 0x43 0x0c 0x00 0x01 0x1B where c is the MIDI channel number (in 0 to 15 format).

This means that every time the program is changed, the current voice data for the selected TG is sent out on all MIDI devices.

However, on power up, the initialisation in MiniDexed.cpp calls ProgramChange (0, i) and then later on calls LoadPerformanceParameters which also calls ProgramChange() again. Both of these calls happen before LoadPerformanceParameters calls SetMIDIChannel to set the MIDI channel for the TG from the performance.ini file.

This means that there are two occasions on power up, for each tone generator, where the MIDI channel is still set to its initialised (i.e. prior to reading the performance.ini file) value of "disabled". As the Enum for MIDI channel is the following (mididevice.h): enum TChannel { Channels = 16, OmniMode = Channels, Disabled, ChannelUnknown };

Then "Disabled" - 1 is 17 or 0x11. Which is indeed the value we see in the 16 instances of the SysEx voice dump sent out on startup.

Not quite sure what the fix is... something in this chain should probably check for a disabled MIDI channel before dumping out voice data maybe? I'm not sure. Also I guess if the MIDI channel for a TG is set to Omni then the voice data will always show "channel 16" ("OmniMode=17" - 1).

I get why ProgramChange always dumps the voice data too, but I can't help think that an editor, if it wants to refresh its data, ought to ask for it rather than "spamming" all MIDI channels ever time a voice is changed...?

And what happens if a sequencer/MIDI file player/etc sends a load of PC messages on all channels at the start? The worst case might be sending PCs on all 16 channels when all 8 TGs are in Omni mode... Won't that cause 128 voice dumps to channel 16 over every MIDI OUT device!?

Thoughts?