Just a placeholder: I am currently creating a mixer object, so a reverb send Mixer (or other sends) can easily be created.

Support the volume knob on MIDI controllers.

(Once #8 is implemented I can say which MIDI message the volume knob sends.)

The latest build contains a version for Raspberry 3 in addition to Raspberry Pi 4.
I could not get it to boot on the Raspberry 3 yet, though.

Currently we can play notes on a MIDI controller (keyboard) and (for testing and debugging) USB (QWERTY) keyboards.

In addition, we would like to support Serial MIDI, to connect older MIDI keyboards that don't come with USB using a circuit like this:

Image Source: https://hackaday.com/tag/6n137/

Connect the wire labeled "RX" to GPIO15 on the Raspberry Pi. This is a SoC number, not the position on the header (see this).

Should we have menu entries to switch effects like Compressor, Reverb on/off?

Suggested menu structure:

• TG1
• ...
• TG8
• Effects
  • Compressor
    • On | Off
  • Reverb
    • On | Off
    • Edit Reverb
      • Size
      • High damp
      • Low damp
      • Low pass
      • Diffusion
      • Send

RTP-MIDI (also known as AppleMIDI) is a protocol to transport MIDI messages within RTP (Real-time Protocol) packets over Ethernet and WiFi networks. It is completely open and free (no license is needed), and is compatible both with LAN and WAN application fields.

I imagine this could be quite useful to, e.g., send sysex from a computer to the Raspberry Pi and to have the Raspberry Pi driven by sequencers on a computer, phone, or tablet, especially since USB gadget mode is not available on Circle (although a Raspberry Pi PIco could probably be used to act as a USB MIDI to serial converter).

The AppleMIDI library contains C++ code for Arduino. It compiles on Arduino, MacOS (XCode) and Windows (MSVS).

I wonder how much effort it would be to port it to Circle.

In case the effort is prohibitive, we might want to use an ESP8266 as a WLAN-RTP-MIDI-to-Serial-MIDI bridge, but using wired Ethernet would be better to reduce latency.

Our objective is to ultimately run multiple Dexed instances at the same time (#12).

Sound generators like the TX816 and TX802 use the performance sysex format. We should support it.

@dcoredump said:

I would like to implement parameter changes via SYSEX

That would be cool!

As suggested in rsta2/circle#280 I investigated the GPIO pinout of the (already known) external devices, which can be connected to a Raspberry Pi, when using MiniDexed and generated a list as a suggestion (see attached).

Two comments:

• The default setting for the LCD outputs RS and RW has changed. Would need to be updated in config.cpp and minidexed.ini.

• We should enable the system option USE_PWM_AUDIO_ON_ZERO in build.sh. This allows to connect earphones or an amplifier to the Raspberry Pi Zero (2) via GPIO12/13 using a small external circuit.

pinout.txt

Over at Reddit, someone suggested adding CV control:

I see the potential for a killer eurorack module !

Even with a minimal implementation, like CV for pitch and algorithm I see a very interesting thing indeed.

Unlike other minicontrollers or MCUs nowadays, Raspberry Pi does not have a built-in Analog-to-Digital Converter (ADC) Circuit.

So the easiest solution might be to built a CV-to-USB-MIDI (e.g., using a Pro Micro ATmega32U4) or CV-to-3.3V-Serial-MIDI (e.g., using a Nano) circuit using an Arduino and feed the MIDI into the Raspberry Pi.

For this, we would need MiniDexed to listen to more than one MIDI input (USB and Serial and/or 2 USB) at the same time. Is this possible @rsta2?

Should I add a chorus instance for each TG?

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.

Inexpensive HD44780 displays like this one are supported in Circle.

Looks like the original DX7 uses a similar 16x2 display.

Although I wonder how to set contrast on this display when not used with such an i2c board that also includes a potentiometer.

Trying to make the aarch64 SD card contents, running into:

https://github.com/probonopd/MiniDexed/runs/5079236408?check_suite_focus=true#step:7:42

make -C armstub armstub7-rpi4.bin
make[1]: Entering directory '/home/runner/work/MiniDexed/MiniDexed/circle-stdlib/libs/circle/boot/armstub'
aarch64-none-elf-gcc -march=armv7-a -DGIC=1 -DBCM2710=1 -DBCM2711=1 -o armstub7-rpi4.o -c armstub7.S
cc1: error: unknown value 'armv7-a' for '-march'
cc1: note: valid arguments are: armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a armv8.6-a; did you mean 'armv8-a'?
make[1]: *** [Makefile:13: armstub7-rpi4.bin] Error 1
make[1]: Leaving directory '/home/runner/work/MiniDexed/MiniDexed/circle-stdlib/libs/circle/boot/armstub'
make: *** [Makefile:[48](https://github.com/probonopd/MiniDexed/runs/5079236408?check_suite_focus=true#step:7:48): armstub] Error 2
Error: Process completed with exit code 2.

If not, the code should be dropped.

If we should need this, the code has to be fixed for keyUp() which isnt' currently implemented. Also there is no way to add velocity to those keyboards...

Looks like https://codeberg.org/dcoredump/MicroDexed/ has effects like this. Do you think these could be put into Synth_Dexed and hence made usable for MiniDexed @dcoredump?

Let's think about how we should best make use of the 4 cores of the Raspberry Pi 4 for tasks like

• Running multiple Dexed instances (ideally at least 8)
• Running effects like Reverb
• Eventually, running some sort of user interface (in addition to MIDI sysex commands)

Is there a way to periodically output the CPU usage of each core @rsta2? We should find out how CPU intensive the various things are and how to best split them up across CPU cores.

Support the sustain button on MIDI controllers.

(Once #8 is implemented I can say which MIDI message the sustain button sends.)

Should we do the following by default?

[all]
boot_delay=0
disable_splash=1
force_eeprom_read=0
gpu_mem=16
disable_overscan=1

[pi4]
# Optimized frequency settings for lower energy use/temperature on Pi 4
arm_freq=600
arm_freq_min=100
gpu_freq=100
over_voltage=-16
over_voltage_min=-16

Let's store the settings for the effects (e.g., reverb) in performance.ini so that one can edit them.

Currently, If two clicks are needed for a single movement. mt32-pi.cfg has this information:

# Set the rotary encoder type (if used by control scheme).
#
# Different rotary encoders may complete different fractions of a Gray-code
# cycle per detent ("click").
#
# If four clicks are needed for a single movement, try "quarter".
# If two clicks are needed for a single movement, try "half".
#
# Values: quarter, half, full*
encoder_type = full

Code is here.

Next step: Try mt32-pi.cfg with my rotary encoder.

DX7 and Dexed only have sine waves. The TX81Z can generate 7 additional shapes:

WAV versions: https://www.audiobombs.com/items/1083/joel%27s-synth-waveforms

The Korg Opsix is doing a similar thing: https://www.youtube.com/watch?v=yS693SgnBws

How hard would it be to implement this in Synth_Dexed (and MiniDexed) @dcoredump?

Reference:
Reddit

Trying to build a 32-bit version for Raspberry Pi 2 too but running into

config.status: executing depfiles commands
make[2]: Leaving directory '/home/runner/work/MiniDexed/MiniDexed/circle-stdlib/build/circle-newlib'
make[1]: Leaving directory '/home/runner/work/MiniDexed/MiniDexed/circle-stdlib/build/circle-newlib'
make[1]: *** [Makefile:879: all] Error 2
make: *** [Makefile:17: newlib] Error 2
Error: Process completed with exit code 2.

https://github.com/probonopd/MiniDexed/runs/5265872462?check_suite_focus=true#step:6:1184

It looks like some issue with circle-newlib. @smuehlst can it be built for 32-bit systems such as Raspberry Pi 2?

Maybe I am missing some necessary "cleanup" steps after having built the 64-bit versions?

Our ultimate goal here is to run multiple instances of Dexed (e.g., up to 8 instances akin to the TX816 and the TX802.

A very typical use case is to create the characteristic "fat" sound by running multiple instances of the same instrument, each slightly detuned and slightly stereo-panned.

As shown here:

• Yamaha TX816 - multiple stacked detuned DX7 voices = epic!
• TX816 Fulltines

Continuation from #69 (comment):

Ah yes, I tried the compressor in the VLC media player, and it's getting louder there, when it is switched on. As I read it, @dcoredump wants to re-work the whole final signal processing stage (use floats instead of int16_t, pan, mixer, compressor, reverb), which makes absolutely sense to me. At the moment, each TG has its own compressor, and as I said earlier, my pan processing + mixer is not ideal. There is much room for improvement in it.

This ticket is a reminder that we revisit the way we set up and use limiter/anti-clipping, compressor, pan processing, and mixer once @dcoredump has re-worked the final signal processing stage. No hurries, just so that it won't be forgotten.

Implement Stereo panning for each Dexed instance.

This is needed to create the characteristic "fat" sound known from the TX816 and the TX802.

Reading

FM Theory & Applications: By Musicians for Musicians
by Dr. John Chowning and David Bristow
ISBN 4636174828

there are lots of example voices that help one to learn FM synthesis. They start by using the "VOICE INIT" button on the DX7. "This function sets up the basic voice data for creating new voices".

Maybe we should have a similar function, e.g., under

TG X -> Edit Voice -> Initialize

It should load the initialization default values:

https://github.com/asb2m10/dexed/blob/11ae4d7ef597b2d52f45e59ab56b342252d0bd88/Source/PluginData.cpp#L230-L239

void DexedAudioProcessor::resetToInitVoice() {
    const char init_voice[] =
      { 99, 99, 99, 99, 99, 99, 99, 00, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 7,
        99, 99, 99, 99, 99, 99, 99, 00, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 7,
        99, 99, 99, 99, 99, 99, 99, 00, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 7,
        99, 99, 99, 99, 99, 99, 99, 00, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 7,
        99, 99, 99, 99, 99, 99, 99, 00, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 7,
        99, 99, 99, 99, 99, 99, 99, 00, 0, 0, 0, 0, 0, 0, 0, 0, 99, 0, 1, 0, 7,
        99, 99, 99, 99, 50, 50, 50, 50, 0, 0, 1, 35, 0, 0, 0, 1, 0, 3, 24,
        73, 78, 73, 84, 32, 86, 79, 73, 67, 69 };

Similar to (De)tune, we should expose the Cutoff and Resonance global Dexed paramters in the menu and save them in performance.ini.

Consider support for a rotary encoder with button.

This could, together with a display, be used for menu based navigation and (simple) parameter editing. But maybe it is not worth the effort to implement menu-based navigation and we should focus on e.g., a a way to edit configuration over the nework instead.

Reference:
rsta2/circle#280

In computer interfaces, double-click is for opening stuff. So I think it would be more natural to double-click in order to go down in the menu hierarchy ("open a submenu"), and to single-click to go up ("close the submenu"). Wdyt @rsta2?

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.)

Formats like VCED and PCED are made to be machine-readable, not so much human-readable. VMEM and PMEM even more so; they were designed around memory constraints of the early 80s.

So the question is, would it be a good idea to introduce human-readable formats (e.g, "VINI" and "PINI")?

Since the .ini data format is widely used and natively supported in Dexed, I was thinking along these lines:

[Performance]
Performance_Name=
...

[INST 1]
Voice_Number=
Detune=
Note_Limit_Low=
Note_Limit_High=
...

[INST 2]
...

Also see page 29 of the TX-802 Owners Manual.

Table Add-10 in DX7II_MIDI_DataFormat.pdf mentions "PERFORMANCE Parameters (PCED, PMEM format)". Those are not for the TX-802 but possibly are similar? https://www.manualslib.com/manual/779968/Yamaha-Tx81z.html?page=74#manual mentions "Performance Edit Parameters (PCED)".

And while we are at it, we might also want to convert those voice sysex (VCED, VMEM) into something more human-readable like

[Voice]
Voice_Name=
Algorithm_Selector=
Feedback_Level=
Osc._Sync.=
Transpose=

[OP 1]
...

[OP 2]
...

NOTE: We may want shorter names for those (ideally standard names), e.g., "ALS" for "Algorithm_Selector" and "FBL" for Feedback_Level. Also see page 30 of the TX-802 Owners Manual and table Add-8 in DX7II_MIDI_DataFormat.pdf.

What do you people think?

@rsta2 wrote

The CHUNK_SIZE [ _HDMI ] parameter should be tuned and decreased for smaller latency. Maybe it should be configurable for the user later

Can I help this tuning by testing on various Raspberry Pi models? I have Zero, 1, 2, 3, 4.
How exactly would one tune/test this?

It would be useful if changes to voice parameters would have immediate effect on already-playing notes.
This would be especially neat in combination with #63.

For some parameters this is already the case (e.g, volume), but apparently not for all of them. More investigation needed.

Do you perhaps know more about this subject @dcoredump?

Right now "center" seems to be 9th dot from the left = 8th from the right?

For me it would feel more natural to have a center ("middle") position for stereo panning, with the same number of dots left and right from the selected setting (maybe even marked with ":" instead of "." to make it easy to spot).

Wdyt @rsta2?

Update: See this post below for a concise user story and a rough idea of how to implement this.

It would be nice if we could assign/"learn" MIDI CCs (knobs and sliders on MIDI hardware controllers) to manipulate Dexed voice parameters.

E.g., these guys:

(Example shows the Nektar Impact LX61+.)

The sliders and knobs all send CCs with values from 0 to 127, and the buttons toggle between 0 and 127: B0 xx 00 ... B0 xx 7F with xx being different for each slider/knob/button. For xx = 07 it is volume, which is already implemented.

You would select, via the LCD, a voice, then select "Edit params", then scroll through the available Dexed parameters using the rotary encoder, and while one is selected, move a slider/knob/button on the MIDI controller, which would make MiniDexed react to this slider/knob/button (=MIDI CC). Then you would rotate the roraty encoder to go to another parameter, again wiggle another slider/knob/button ont the MIDI congroller, and so on. (The assignment should be written to an INI file in order to survive a reboot.)

Imagine that. A "DX7 with more than one Data Entry slider". Isn't that what people would have wanted already back in the day? ;-)

For those without a fancy MIDI controller with many siders and knobs, you could select a Dexed parameter on the LCD UI, then click the rotary encoder button, and then rotate the rotary encoder to manipulate the value of the selected Dexed parameter that way. (Edit: @rsta2 has implemented this in https://github.com/probonopd/MiniDexed/pull/61)]

Should I add a delay for each instance?

I open this separate issue, because we will probably have to deal with this problem for a while.

Problem description

When quickly playing on an USB MIDI keyboard controller, connected to a Raspberry Pi 1-3 or Zero (Raspberry Pi 4 is not affected), notes can get stuck, i.e. the respective tone is played forever, even after releasing the key. This can be reproduced with continuous voices (e.g. organ) playing rapid glissando for a while on the following keyboard:

• M-AUDIO Keystation Mini 32 Mk3

Workaround

The problem may be reduced or solved with the following option in the file cmdline.txt on the SD card:

usbspeed=full

This switches the whole USB from high speed (480 MBps) to full speed (12 MBps). The most USB MIDI controllers do only support full speed, so this is generally not a problem, but a few other keyboards do require high speed mode to work. The workaround does not work there and cannot applied by default.

Using M-Audio Keystation Mini 32 MK3, getting Transaction failed (status 0x202), Transaction failed (status 0x402) when playing many notes at once or in quick succession.

Raspberry Pi 2 and 3 with sndhdmi

• Transaction failed (status 0x202)
• Transaction failed (status 0x402)

Raspberry Pi 2 and 3 with sndpwm

• Transaction failed (status 0x402)

As a result, notes get not played or notes get sustained. Looks like individual key down/up events are missed.

To reproduce, play e.g. quick glissandos.

Just a question: Is m_nNoteShift[] currently used? Synth_Dexed has methods for this:

void setTranspose(uint8_t transpose);
uint8_t getTranspose(void);

It would be neat if we could have a shortcut for switching between OPx, like we have a shortcut for switching between TGx.

We could use the same "gesture": keep-button-pressed-and-rotate-knob. If there is "TGx" in the upper-right corner of the screen, it would go through the TGs (as it is now). If there is "OPx" in the upper-right corner of the screen, it would go through the OPs (new).

Wdyt @rsta2

Using I2S sound boards would be very nice, because real 16bit/44.1 KHz audio sounds much better than 12(?)bit PWM.

Currently only one MIDI USB device is being used. minidexed.cpp has

(CUSBMIDIDevice *) CDeviceNameService::Get ()->GetDevice ("umidi1", FALSE);

What would we need to do if we wanted to support more than one USB MIDI device?
Use cases might include

• USB MIDI foot controllers
• USB MIDI sequencers
• Multiple keyboards
  etc.

klonk2905 wrote over at Reddit:

Hey, I'm willing to collaborate on the hardware part.

A "hat" with decent power supply, quality DAC, and dedicated sliders/controls will be top notch at some point, and that is something I can help with.

Let's collect the ideas and requirements here.

• Alphanumeric 1602 LCD Display
• KY-040 rotary encoder
• Footprint to solder in GY PCM5102 DAC module (schematic) and the CJMCU 5102 DAC module
• Serial RX/TX DuPont header pins (for 3.3V serial speaking MIDI, e.g., to connect to a computer using a Raspberry Pi Pico)
• Footprint for optional Serial MIDI circuit (for "real" MIDI devices)
• Needs to work with all Rasperry Pi models
• (Deprioritized) Optional circuitry for using analog control voltages? (for Eurorack use)

Basically a https://github.com/gmcn42/clumsyMIDI but with 1602 LCD and rotary encoder.

Would it be possible to record midi and/or wav to microSD and/or USB storage, at least on the more powerful models?

Sound goes bad when 8 keys are pressed simultaneously.

Is this caused by clipping?
Does this also happen in MicroDexed?

cc @dcoredump

What about adding (later) a UI for a Touchscreen (connected via HDMI/USB), so voices and setup can be configured with?

If not, the code should be dropped.

I personally don't need this because my experience is that an external HDMI->Audioconverter adds too much latency.

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

I didn't find this exact information in DX documentation but the "MX49/MX61 Data List" PDF says:

Bank Select and Program Change numbers that are not supported by Yamaha will be ignored.

@rsta2 you are already doing this for the rotary encoder and it seems like we should be doing the same for MIDI Bank Select and Program Change messages.

Let's output MIDI messages to the screen and/or to serial for debugging and development.

We will also need this if we want MiniDexed to act upon special MIDI messages outside of Synth_Dexed.

Since MIDI is processed inside Synth_Dexed, would we need a callback of some sort in order to get the MIDI messages?

@dcoredump wdyt?