Stress test of the Deluge comparing FW 3.15 and FW 4 (community)

Testing setup

• Deluge 7seg
• original SD card 32gb formatted with mac OSX 32kb cluster size MS DOS FAT
• newer deluge model (no old bootloader)
• 2 firmwares (original 3.15 from SA / FW 4 community edition from 03072023)

Test

• flashed the Deluge to FW 3.15
• made a song with long releases and too much tracks (lots of arps + delay + unison)
• resampled reference song in 3.15 playing through with no dropouts
• refreshed the Deluge with newer FW 4
• opened the same song and resampled playback

Result:

• newer FW 4 keeps dropping voices with the same song
• especially audible in the longer releases of the keys (1st clip top)
• dropouts variable in length
• 3.15 plays stable

all files can be found here:
https://drive.google.com/file/d/1-AR-5WxnJaHFXip0Gsh2bOirj1FZE5I0/view?usp=sharing

It would be great to save the brightness settings permanently.

This seems to be the most requested feature from users. The ability to have Deluge export individual tracks would make it far less tedious to take a song and finish it on a computer. I've seen users suggesting different methods for this, so I'll describe a couple and maybe this can serve as a basis for discussion around other ideas and which would be best to implement.

1 - Batch track export

This would be an automated way of recording each individual track in a song. I'd imagine the process as:

1. Select a track and time range for export.
2. Confirm selection.
3. Deluge automatically plays though each track, recording in realtime.

Notes

• Ideally with this option the files should be in some way colocated with the song and named appropriately like [song]-[track].wav.
• Running this could take quite a long time to complete, but it would still be far better than having to do all this work manually.

2 - Track freezing

Another option would be to allow for freezing of tracks. It's possible that this would be the same as the prior option at its core, but once a track was frozen, playback would use the frozen version instead of the live one - allowing a user to save on CPU / Ram.

Additionally it would probably be helpful to allow for batch track freezing. I could imagine a UI like:

1. Each track becomes individually selectable using pads.
2. Confirm selection.
3. Deluge records each track.

Notes

• The frozen versions would need to be saved along with the song similarly to how it would work with batch track export.
• There would probably need to be some way to visually identify frozen tracks.
• What would the process look like for unfreezing a track?

3 - Deluge as a multi-track audio interface

This option is the most nebulous to me. If it were possible to have Deluge act as a multi-track audio interface, then maybe users could simply record directly into their DAW. I'm sure an option like this would have limits. Some questions:

• How many tracks could Deluge simultaneously offer?
• Would there need to be a way to configure which output each track would be sent to?

Additional thoughts

I'm not sure if the offline nature of this options 1/2 grant any possibility for non-realtime rendering, but it's probably something that's worth looking into. Maybe there are optimizations that could be made like detecting silence in tracks and then creating a silent region of the same length as the remaining time until the next audio starts and skipping to that point. I'd imagine that batch export would be painfully slow without some optimization like this.

Would love to hear back from active devs on what seems like it could be possible here!

Using 7SEG release bin from latest community build https://github.com/SynthstromAudible/DelugeFirmware/actions/runs/5359807075

Steps to reproduce (7SEG only):

• load latest community build (from above)
• power cycle (to reset defaults for menu option later)
  should be in a new synth 0
• choose menu shortcut LFO1-SYNC
  should display [oFF ]
• (select, scroll left) [28t ]
• (select, scroll left) [4th ]
• (select, scroll left) [2nd ]
• (select, scroll left) [6th ]
• (select, scroll left) [th ]
• (select, scroll left) [th ]
• (select, scroll left) [nd ]

Note that (select, scroll right) the first few options look OK. But eventually it'll loop around to the newer options, as above.

Expected behaviour 7SEG

• all the menu options should be readable
• any menu options longer than 4 characters should scroll to show the full string (these are best avoided if possible).
  tested by @chrisbc on &7SEG see #108

Expected behaviour OLED

• all the menu options should be readable

In addition to the isomorphic keyboard, with a 16x8 button matrix, we can create an 8 octave piano keyboard.
And bind this piano keyboard to the second click of the "Keyboard" button (or switch keyboard type in the Settings menu).

This is part of the pre-OLED to post-OLED firmware inconsistencies I've noticed after loading the open-source community firmware onto a 7-SEG display Deluge. (See #76, #97, #98 #99, #101)

Unable to search for non-existent songs/folders anymore

Video showing the inconsistency: https://youtu.be/PXD9Psp94UI

• Unable to type characters into keyboard if a project or folder doesn't start with them.
• Deluge points you to a song closest to the input but 'rounds down'.
  (No songs starting with '6', you have a song starting with '4' and '7':
  If you type 6 it will reveal song starting with '4'. It doesn't reveal song starting with '7' since it 'rounds down'.
• (Not in video) Inconsistent 'suggestions' based on last input.

Extent of issue

This is confirmed with:
[X] Folders
[X] Songs
[X] Kits
[X] Synths
[X] Sample file browsing
[X] Sample folder browsing

Replicable on OLED?

Can you enter non-existing song/folder names when searching via keyboard after hitting Load? OLED displays 3 items at a time, does it round down based on what you give it?

Should this new behavior revert or stay?

I prefer to know if a song I thought existed doesn't exist on my SD card rather than inputting characters which then won't display on screen. However maybe this behavior has value since it will always point you to somewhere?

When you're playing a song and load another to start on the next round the master compressor settings for the next song apply as soon as you hit LOAD, not when the next song starts as expected.

Reproduce:

1. Create a song with no master compressor settings
2. Create a song with heavy master compressor settings
3. Play one and during playback load the other
4. You'll notice as soon as you hit LOAD the new master compressor settings take effect, even before the next song starts

In a live situation this could be quite alarming to both the performer and the audience.

This may be a known limitation of the master compressor or something that is considered intentional behavior.

Deluge 7-seg with latest community dev build from 1124f4a

When using the keyboard or drum keyboard, a pad that's being held before recording starts will not be included in the recording. This is especially relevant when playing in mono/legato patterns where you might hold a low note while alternating over higher notes.

To replicate with the synth keyboard:

1. Arm recording
2. Hold down a note
3. Press play
4. Let go of the note before the clip finishes
5. Observe that no note exists in the recorded clip

It's basically the same with the drum keyboard, but in that case it probably only makes sense to try to catch sounds which are using the cut, loop, or stretch modes.

Add an option that auto learn a midi controller (Without having to press the learn button) and automatically send to selected channel in clip mode.
I have almost never used my deluge because of that missing feature. Having to unlearn and relearn every time I switch track for controlling many external synths is a pain and make the deluge unusable for live performances.

From a discussion on Discord earlier today: https://discord.com/channels/608916579421257728/1118654563596128336/1121185820854980678

In the waveform editor, the following shortcuts should work:

• Vertical scroll encoder should swap the currently selected endpoint in the order
  1. start
  2. loop start if pulled out
  3. loop end if pulled out
  4. end
• Holding down the select encoder while moving it should snap to zero crossings

This is part of the pre-OLED to post-OLED firmware inconsistencies I've noticed after loading the open-source community firmware onto a 7-SEG display Deluge. (See #76, #97, #99, #100, #101)

Saving new iterations of songs inconsistencies

Video showing the problem: https://youtu.be/Vx7kILI1NwQ

• The iteration will now generally add a '_1' to the end of the title instead of ' 2' for the first iteration.
  (However, you can sometimes experience it adding a '_2' at the end instead by loading/reloading/trying to save again as show around :52 of video).
• Sometimes after hitting save, the display won't skip to the end of the title as expected and just show the start of the title (7-SEG display, title would have to be greater than 4 characters)
• Underscores are present between song title and iteration number, wasn't present before unless currently scrolled to that space's position.

Extent of issue

This is confirmed with:

[X] Song iterations
[?] Synth iterations
[?] Kit iterations
[?] Folder iterations

Replicable on OLED?

It would be helpful to know if the behavior is the same on the OLED Deluge. Does the OLED scroll to the end of a long title title that extends beyond the display? What number does it start with for the first iteration? Do underscores appear between title and the iteration number? etc

@bfredl mentioned this on the discord, https://discord.com/channels/608916579421257728/1107026299945496577/1116778630656299098.

maybe this already has been discussed but one thing which I'd like to see: A "virtual 7seg" build mode. Build the entire UI/menu system with HAVE_OLED set to false, but add a separate flag to still build the low-level oled driver. then write an oled rendering routine which emulates the 7seg display.
The main usecase is of course debugging/testing ui code, if you have an OLED deluge you can debug how your changes will behave on a 7seg deluge

In the general spirit of Synthstrom's approach to supporting the 7seg, we probably want to make sure any features (enabled by default only?) that get merged to community support the 7seg well.

Technical sketch:

• Use the existing HAVE_OLED to mean that we're using the OLED UI, to minimize churn in the upper/UI layers
• Introduce a new define, DELUGE_DISPLAY (bikeshed name) similar to DELUGE_MODEL which is used by the lower layers to switch between physical OLED and 7SEG output.

When in the DrumKeyboardScreen (from #112), I've found that if you hold a pad for one sample and then press a different pad for the same sample but at a different velocity, it does not retrigger the sample at the new velocity. This seems counter-intuitive to me and would make it more difficult to play in complex parts with ghost notes as it's quite easy to accidentally hold a pad a little too long and swallow a note.

This is part of the pre-OLED to post-OLED firmware inconsistencies I've noticed after loading the open-source community firmware onto a 7-SEG display Deluge. (See #76, #98, #99, #100, #101)

Kit/alphanumeric order inconsistencies and crashes.

Video showing the problem: https://www.youtube.com/watch?v=iq0kG6glywE

• The alphanumeric ordering seems to be changed

1. Expected: A1, A2, A3, B1, B2, B3, C1, etc.
2. Observed: A1, B1, C1, loops through a shortened list of kits, A2, B2, C2...inconsistent and unpredictable.

• A crash can occur when messing with the improper order found in the community firmware.

1. Certain kits aren't showing up at all, but can be revealed when scrolling backwards then forwards.
2. Doing so enough times causes a crash.

Replicable on OLED?

It would be helpful to know if this issue persists on an OLED Deluge. I would suggest adding kits A1, A2, A3 through H1, H2, H3 yourself and sharing the behavior.

As discussed in the Discord today, there's a problem with how non-JLink GDB Servers and OpenOCD address the Renesas chip that prevents setting of proper breakpoints and causes failures to run freshly loaded firmware.

A subset of us are actively working to get to the bottom of it. All debuggers other than JLink+JLinkGDB are likely affected.

This is in the works! Stay tuned!

The scripts will be in a combination of Bash and Python using SCons as the make system, borrowing liberally from the excellent cross-platform firmware build scripting at https://github.com/flipperdevices/flipperzero-firmware (also under GNU GPL).

Sysex messages allow midi devices to send arbitrary data in form of 7-bit messages. These take the following form:

F0 manufacturer_id_byte {arbitrary 0-127 byte values} F7
F0 00 manufacturer_id_1 manufacturer_id_2 {arbitrary 0-127 byte values} F7

manufacturer ids are normally allocated by the MIDI association, but there are ranges of ids which are "reserved" which can be freely used with some risk of collision.

Allow multiple sysex consumers

It will expected that various extensions to the community firmware will want to use sysexes for various purposes. Here I am using "extension" quite liberally, both for features which end up in the shared community branch and also for stuff people will work on and distribute in private forks (with no direct intention for merging)

I propose we set up some kind of standard for how sysex messages are prefixed, so the MidiEninge can "route" messages to the extension which can handle it and discard ones it doesn't know about.

Generally, a deluge-compatible sysEx (both sending and receiving) will have the following form.

F0 {deluge manufacturer prefix} {extension prefix} {arbitrary 7-bit data defined by the extension} F7

Thus incoming messages can be handled something like this

// invoked by the serial and USB midi drivers after buffering
// a complete sysex message (and filter out high-prio system messages etc)
void handle_sysex_message(uint8_t *data, int len) {
    // data[0] is always F0
    if (data[1] != DELUGE_MANUFACTERER_ID) {
      // out of scope for this proposal, but would be possible
      // handle_foreign_sysex_msg(data, len)
      return;
    }

    int extension_id = data[2];
    switch (extension_id) {
        case 0: // transport control
            Song::handle_sysex(data, len); break;
        case 1: // transfer XML/WAV files over sysex etc
            storagemanager::handle_sysex(data, len); break;

        // these could come from merged branches from forks
        case 10:
            my_private_fetaure::handle_sysex(data, len); break

        ...

        default:
            // do nothing, print to log in debug mode?
    }
}

The final code will be more complicated as the deluge manufacturer id and the extension id could be longer than just one byte.

When sending messages, extensions will be expected to use the same prefix.

This assumes that individual messages cannot be streamed. extensions will only receive complete messages with a maximum, static size and are expected to break up long data transfers into many small sysex messages. This is what we want anyway to avoid head-of-line blocking of USB midi ports, so normal note messages can be sent interleaved

I've already experimented a bit with sysex handling, and a solution like this as part of MidiEngine.cpp should be approachable, but I am opening this issue to solicit feedback over a reasonable, forward-compatible design before working on a PR.

open questions

• pick a reasonable "manufacurer prefix" for the over all deluge device. Barring getting a standardized manufacturer id for synthstrom (unrealistic?), we need to pick a value in one of the ranges which are reserved for private use.
• determine reasonable lengths for the prefixes. with two bytes we will have 16384 unique ids.
• coordinate extension numbers for third-party extensions. this could could be a wiki page or something more organized

Convert 7-bit sysex data to 8-bit clean data

This is less of an immediate concern, but there is gonna be a need to send blocks of full 8-bit byte values.
There are standard solutions like this. Like sending the low 7-bits of a bunch of bytes then the highbits
collected to a single bytes (I've seen DSI/sequential synths doing this), which I used in my data transfer tests.
This could be exposed as utility functions so extensions won't need to reinvent this particular wheel.

Just build from origin/community and noticed that external MIDI devices connected via USB are not visible under Settings -> MIDI -> Devices.

They are visible with last official 7-segments Synthstrom firmware V4p0p1 and with firmware released by @alter-alter in his fork here: https://github.com/alter-alter/DelugeFirmware/releases/tag/1.0.5_randomizer

Steps to reproduce (darwin, macOS 12.6.5):
git clone https://github.com/SynthstromAudible/DelugeFirmware && cd DelugeFirmware && ./dbt dbt-build-debug-7seg

I'd love to see support for a sustain pedal, i.e. Midi CC64. There is also interest expressed in the forums.

I'm willing to try implementing it myself, as soon as the cross-platform build scripts are available. Maybe anyone has any pointers on how this is usually done.

This is just to gauge interest, and maybe collect some additional requirements/wishes, so let me know what you think.

After #117, most Deluges can boot. However, the oldest bootloader revisions do not seem to be able to boot. @alex-r-t has kindly provided some builds (on discord) which differ only by the linker script. Using Rohan's original linker script, which places .bss before .reset, works on very old bootloaders, while current top of tree (which places .reset before .bss) does not.

The existing deluge filters have a fixed configuration of a low pass ladder filter into a high pass ladder filter. The goal of this issue is to switch it to something more like the hydrasynth, where the LPF would have a variety of models to choose from and the HPF is replaced by an SVF that's continuously variable from LP to band or notch to HP. This opens up a ton of possibilities for sound design by

Main goals:

• Augment HPF ladder filter with a morphable (low-band/notch-high) SVF. Maintain a classic switch to use the existing HPF
• Enable series/parallel switching of the two filters
• Enable oscillator routing separately into each filter not feasible without overhauling oscillators
• Add additional filter types to LPF slot (SVF, vocal, BPF bank, maybe more)

Side goals:

• Refactor filter code to separate ladder filter code from filter configuration #304
• Refactor filter menu and configuration code so that a single list of filters can be maintained and automatically populate menus and configuration (mostly)

I'm transferring the progress tracker from my PR to this issue so that PRs can be incorporated when usable before the entire issue is complete.

The FM synth could be expanded to allow selecting between waveforms rather than just sine. In order to do this without aliasing the maximum frequency generated by the underlying oscillator must be able to be configured dynamically, using a method such as blep/blit.

The maximum frequency cutoffs for an oscillator to avoid aliasing can be calculated by inverting the methods in chownings 1973 paper.

Some filters would have to be enabled for this to be useful - the SVF or a simple LPF without drive would minimize the impact on voice count

The new svf filter is great. The only issue I found is that when engaged, the filter cuts a lot of high frequencies by default. So doing a filter move is not really possible because there is no way to get the original sound when svf is selected.

for now, the scrolling of the 7seg display is not working anymore. sure, it was distracting to repeat the scrolling forever. but having not even one scroll initially and being forced to scoll manually makes the display even harder to read then with scrolling.

I suspect this behaviour was introduced in either of these PRs:

#176
#178

I also disabled OLED text scrolling because i find it incredibly distracting. I simply commented out a line in View.cpp.

Suggestion:

• revert to the original scrolling by default
• have an option to scroll only once and then stop
• another option to never scroll
• additionally: scroll speed setting for slow / medium / fast

This is part of the pre-OLED to post-OLED firmware inconsistencies I've noticed after loading the open-source community firmware onto a 7-SEG display Deluge. (See #76, #97, #98, #99, #100)

Scrolling through title position now displays keyboard.

Video showing the inconsistency: https://youtu.be/zBvPcSGLN04

• Scrolling through a title on 7SEG will then prompt the alphanumeric keyboard to pop up. This wasn't the case prior.

Extent of issue

This is confirmed with:
[X] Folders
[X] Songs
[X] Kits (not an issue: alphanumeric keyboard will always be on display when loading a kit)
[X] Synths (not an issue: alphanumeric keyboard will always be on display when loading a kit)
[ ] Sample file browsing (does not display when scrolling)
[ ] Sample folder browsing (does not display when scrolling)

Replicable on OLED?

It would be helpful to know if the behavior is the same on the OLED Deluge.

Should this new behavior revert or stay?

If a user is scrolling through the title, it might mean they want to type something or delete from that point where they scrolled to to find a similar file. However, sometimes the user just wants to see the rest of the song title. By popping up the keyboard when scrolling, it adds to visual noise.

There is something wrong with the 4.14 alpha 3 and saving / folder viewing on a 7seg. Instead of hiding the automatically created sample folders it shows them. This was a feature that seemingly never made it into the open source version. In the official release of the fw it’s correct.

Using 7seg deluge, tested before and after this merge. Loading firmware from SD card resulted in unresponsive Deluge on commits after 884da39 until the change was reverted.

@stellar-aria has a bug fix in the works.

Now that DBT is in community there is a laundry list of stuff I want to add to it but I'll start with the following:

• Disable default build in favour of listing targets.
• Build stats on completion, sizing, etc.
  • Danger-checking/warning for .bin size 0 or oversize .bin
  • Output .siz file as e2studio does
• Test for or just provide some notice that libcrypt.so.1 is needed, maybe with some instructions.
• Dynamic version string (eg: "c20230619-a1b2c3d-d" in the scheme: <c for community><yyyyMMdd>-<git_commit>-<build type: "r" or "d">)
  • DBT pre-runner for preparing things before a build, to be called by e2 studio and other editors prior to building.
• Direct target support / multitarget (eg: ./dbt dbt-build-debug-oled dbt-build-release-oled etc.)
  • Fix compilation db (compile_commands.json) to output to the build directories
• Debugger shortcuts
  • DelugeProbe/CMSIS-DAP and FTDI compatible openocd + gdb shortcuts
  • JLink support with whatever tools they use (know very little about JLink, but have some starting points from over at the Flipper Zero repo)
  • Quick, commandline "install" support via debugger-based hardware flashing
• Restructure to make more modular in prep for all the above ^^^^^
• Touch .map file so it gets cleaned up with the rest of the targets.
• clang-format runner
• DBT-Toolchain v8 changes
  • Include clang-format
  • Remove cmake
  • Fix mac dotfile pollution
  • Increment version in bash/batch script downloader.
• --nowo, --no_owo, --no_uwu (remove progress indicator) param

More to be added.

Playing around with Kconfiglib is on my to-do list here as well, but I'm not sure I have a specific goal in mind with it yet or idea of how it fits. Once I do, expect some checkboxes to be added.

Pie-in-the-sky / requires a lot of other things to be in place:

• Test and/or test framework runner
• UF2 image support (should work with DelugeProbe and maybe even USB Mass Storage eventually...)
• USB interface?
  • Maybe some midi sender/receiver mocking capability for putting the Deluge through its paces
  • DFU loader support

I've observed this behavior using the a recent community build for 7SEG. (June 23, 2023)
Found here: https://github.com/SynthstromAudible/DelugeFirmware/actions/runs/5359807075
'release-7seg.bin'

Video demonstrating bug: https://www.youtube.com/watch?v=lYFI56dkVE8
(Skip to 1:00 for another way to reproduce the bug via TEMPO knob)

How To Replicate

1. Press Play
2. Go to Keyboard View
3. Repeatedly press one note
4. Observe multiple inactive pads light up

Alternatively:

1. Press Play
2. Enter SONG view
3. Turn TEMPO knob up.
4. Observe multiple inactive pads light up.

Sometimes pads will stay LIT until you leave the view.

This does not occur with the initial Community Build 7SEG firmware.

Can someone replicate with OLED?

When using midi out with the drum mode, there is no way to use the CC banks of each row/ even one row.

It would be super handy for drum machines if we could just use each drum row's 16 adjustable MIDI CC.

A big "thank you" for all the current clever developers pushing the envelope and expanding this already great device.

Description

Some synths and electronic pianos have the ability to add user-defined scales that differ from 12-tone equal temperament (12TET). This is usually enabled by allowing the user to set an offset (in cents) for each of the twelve notes in an octave (N = 12), and additionally by sending SysEx messages to the instrument.

I suspect I'll mostly be taking the lead on implementing this, but feedback/advice is welcome.

Incorporating some of the feedback received, the acceptance criteria section has been updated.

Acceptance criteria

• A menu available in Song mode will allow specifying the tuning of each note, and the desired root note
• Pitch adjustment applies when performing any synth instrument (Subtractive/FM/Pulse)
• Persist tuning banks to SD card
• Persist select tuning bank when saving a song
• Read tuning bank into memory when loading a song if specified and present, reset to 12TET otherwise and warn if bank not present
• Reset tuning data to default (12TET) in new song

Stretch goals

• Pitch adjustment applies when performing synth sample
• Pitch adjustment applies to outgoing CV
• Ability to set a tuning bank for a single instrument track
• SysEx Implementation following MIDI Tuning specification
  • SCALE/OCTAVE TUNING DUMP, 2 byte format or SCALE/OCTAVE TUNING 2-BYTE FORM (NON REAL-TIME)
  • KEY-BASED TUNING DUMP
  • SINGLE NOTE TUNING CHANGE
• Support for N divisions per octave where N != 12
  • This is currently included under stretch due to the amount of changes required for N = 12 being much smaller than N != 12 owing to noteWithinOctave being quite prevalent within voice.cpp.

Open questions

• Should we enable persistence of tuning banks beyond Song mode by leveraging Flash storage or prefer loading from SD card? Answered: We will persist tuning banks as Scala files on the SD card.
• No menu is currently available from Song mode, so adding it here seems logical.
  • The argument could be made to somehow involve the Scale mode button, though this might confuse the two features. I'm open to feedback.
  • The current implementation adds a submenu to Settings, which is convenient because it can be accessed from keyboard mode where you can trigger notes while altering the tuning.
• How to handle Scala files with greater than 128 divisions.
  • Ignore and apply partial scale?
  • Reject the file and popup a warning?
  • Wait until MIDI 2.0 is implemented?
• QWERTY or basic menu for selecting Scala files?
  • Optimize for searching through many tunings?
  • Optimize for being able to play each tuning in keyboard mode while scrolling?

Examples

N = 12

Root note is C, offsets follow Pythagorean tuning.

When "Root Note" is changed, the note names in the left columns will rotate (e.g. D becomes 0.00, D# becomes -9.78 and so on), and the pitch adjustment will occur on the specified notes.

N != 12

For the case of N != 12 the note names will need to change. We could represent the note's name as a numerical index, or by the assigned MIDI note name (e.g. B 3, C 4, C#4, etc).

Long-term, this may grow to feel like a Scala file editor with the ability to input ratios as well as cent offsets.

Discovered an issue with how the Pan parameter is being displayed on the OLED screen, both when changing the param using the select knob and the gold knob. See attached picture.

I am using the latest community build.

To replicate bug:

1. enter a clip
2. press shift + master pan
3. turn gold pan master fx knob or turn the select knob to change the parameter value

Tested with community build on 7SEG https://github.com/SynthstromAudible/DelugeFirmware/actions/runs/5478105923

Steps to reproduce

• SHIFT+NEW = new song (defaults to new CLIP)
• select KIT (default KIT 0)
• add a few beats - e.g. KIK, SNA, KIK , SNA
• hit PLAY
• select AFFECT-ENTIRE
• dial in a little SAMPLE-REDUCTION (CUSTOM-1), 1 bar is enough
• select CUTOFF/FM
• now, mind your ears, press-click lower GOLD encoder twice (to engage SVF) and we have immediate self-oscillation.

At this point the SVF filter is in default with MIN resonance and MAX cut-off,
NB: the feedback can be killed by either:

• setting sample-reduction off
• lowering the freq on SVF filter

This may be relevant to #105

Issue from discord

Midi hosting is not working properly for devices with multiple ports. Current implementation checks the port in the message and only passes if it's a port that has an associated profile, but the USB host driver side can currently only connect to the first port

If a kit row is mapped to a midi note then it will be triggered by both MPE and non-MPE inputs

The simplest fix is to not allow MPE input to kit rows however I believe that this is a deliberately supported feature based on the documentation from when MPE was added to the deluge.

To avoid that I'll look for a way to store and check an MPE zone within the offerReceivedNote function with minimal other code changes

It would be nice to have a new "Settings" option that allows us to switch the classic Deluge clip lunch layout to something similar to the Ableton/Bitwig/Logic view.
With columns of instruments and rows of patterns.
We can launch clips by clicking on them, or launch an entire "scene" consisting of patterns in a row.
The record function allows to store the clip launching sequence in the arranger mode (similar to the Push functions).

Labels: Suggestion, Enhancements

Good morning,

This is amazing. This amazing. This is amazing.
I've been dreaming of making a specific plugin for my deluge for ages...

It'd be great to see a bit of documentation.
How to get started, where to look for, etc.
I would suggest a short architecture diagram of the code for a starter.

Then later, i would really like to know more about what is possible in terms of plugins - does the binary artifact have to be monolytic? Or can it accept additional components without having to recompile the entire thing?
I'm thinking distribution channels - would someone be able to get a plugin from a third party and flash it on the side, or would each plugin need to be flashed as part of the main firmware and therefore only one custom functionality could be added?

Lastly - are the binary artifacts required to be signed, is there any secure element onboard that would prevent someone to do certain things?

Thanks.
This is amazing. This is amazing. This is amazing.

A few possible options for implementation:

• Menu setting to turn shift in to a toggle (probably need this regardless
• Tap shift 7 times for sticky keys (it must play the sound)
• Midi CC learn (this is a good stretch goal, but may be more technically complex)

Problem statement

Recently I wanted to experiment with recorded audio, and some random, not-so-beat-centric musical ideas. Currently deluge is very eager to do the stretching and make everything fit the grid neatly. I searched the forums for answers/workarounds (see forum links below) but finally, after recording clips in deluge I had to export them and use SooperLooper to achieve what I wanted.

related Synthstrom Forum threads:

• turn-off-automatic-time-stretch
• no-timestretching-in-arranger-for-audio-clips

Outline

Here we'll try to switch off time stretching to see how useful this option is. Basically its an excuse to get my hands dirty with the newly opensource Deluge Firmware.

Done criteria (OG)

• mupaduw#2
  Does it work? Does it sound good? what are impacts? Try recording, overdubbing, importing audiofiles.
• a way option to toggle this behaviour on/off without reloading firmware.

Done criteria (from feedback)

• mupaduw#4 WONTFIX
• mupaduw#6
• mupaduw#7
• persist settings to song XML file - with backwards compatability.
• setting to determine end-of-loop syncing behaviour deferred

Steps to reproduce:

• kit with a sample row
• enter kit 16 levels kit view
• trigger one of the velocity buttons and hold it down
• trigger another velocity button from the same kit item

Expected behavior would be to hear a second sound. But it just stays silent.

It would be preferable to hear the second trigger too, making finger drumming much easier and accessible.

The current keyboard view (i.e. "playing" Deluge notes ) supports a +5 semitone (fourth) row offset / tuning. This task is to allow users to set different layouts for display. Reasonable options run from +3 to +8 (octave).

UX TBD, but one possibility is shift + piano_keys + <> (| ^v). (Alternatives?)

(We could also consider other irregular options such as guitar, with the differing G-B offset, or a whole tone layout. As that looks like a more complex change it probably makes more sense as a separate task.)

For a similar implementation, see "Row Offset" in Linnstrument options #below:
https://www.rogerlinndesign.com/support/linnstrument-support-panel-settings

A second USB midi upstream port should be enabled to separate MPE zones from normal midi channels. I am happy to work on this

(No PR done yet, I’ll first write my plan as an issue and I plan to start next week on it, but I am writing this to check if people have ideas or feedback)

Currently a clip can be edited with scale mode on (7 notes) or scale mode off (12 notes). The 7 notes views are far, far more easy to navigate since a full octave is always in range of the 8 vertical lines of the display. However, you cannot have notes outside the key once you turn this mode on.

This issue describes an enhancement that allows entering “out of scale” notes while scale mode is on, in a way that does not break the existing transpose functionality and key detection functionality.

basic idea and data model

The basic idea is to add a pitch offset attribute to each note. This attribute starts on 0 when the note is created/placed. The existing scale detection and transpose logic can be unchanged, it will operate on the unaltered pitch only.

UI

How will the change be accessible in the UI: it seems the most logical way to do this is pressing the note and turning a knob simultaneously. However, all encoder knobs already do something in combination with a pressed note. So I thought the most easy solution would be to have the main encoder, that also does note probability and 1:2, 1:3,2:3… and so on just display a second value after you press it to confirm the probability value.

so, note + press encoder : probability value shows (turn to change) , press again : accidental value shows (turn to change) , press again: back to probability.

what will be displayed as accidental value.

If the offset value is 0 the string “UNC” (for LED) or text “Unchanged” will show. If an offset value is present then the pitch of the note after modifying it with the offset will be displayed. An alternative solution would be to display the offset itself as a signed number, but I think for most musical applications it will be more informative to see the pitch rather than the offset and still have to calculate the pitch in your head.
If you turn the encoder the offset value or displayed pitch will change. Whenever the offset will be 0 the text “UNC” will appear again.

some open questions

• it would be nice to color notes slightly different in a more distinguished way than they just being one semitone higher/lower once they have an non zero offset value assigned. I do not know how note coloring exactly works on the Deluge and I have no plan yet what a good informative way of displaying could be
• if this idea is going to work I need to track down every usage of pitch in the sound engine because it may have to be modified to pitch + offset (with some max min clipping). Does this need to be precomputed and stored in the note or will it not significantly affect processing speed?

Hi,

I am planning an implementation of a default midi mapping which applies on the current selected clip.
Similar as things work on elektron devices.

It could work like this:
Setting up one Midi channel in settings (..Default midi channel ..auto channel) - on this channel a Midi table applies just for the selected clip or kit. This could include Notes for kit rows by number to play drums with pads and notes play the selected synth clip.

Due to the multiple clip architecture of the deluge - I guess, that this is the only way of implementing a predefined midi mapping.
This would be a very big deal for everyone I guess: We could map a controller, go in a clip and instantly change all parameters.
I find, that I am really lazy with changing shortcut-parametes.

I think this will take me forever to implement - I am C# guy and dont have jlink or so - but love the deluge like we all :)
And don`t know how to set the label #enhancement :)
What do you think?

Pending! This will cover building and debugging in combination with the build scripts TBD in issue #7.

Still exploring the official Renesas VSCode extensions, but it's likely I'll keep it minimal and use only one or two of the related extensions given the draconian licensing accompanying Renesas's .vsix files.

As per the standard for community open source projects, it makes sense that there should be a Contributing Guidelines defined in the repository, à la defined in the github docs here.

This would help enforce a standard for development and prevent wasted time correcting PR's with conflicting approaches or formats etc.

This pertains to #17

Would like this feature to be toggle-able (ON/OFF) in the Community Features Menu.

When quickly turning a gold parameter knob (ex: changing HPF frequency (see video attached)) the parameters hang and/or jump forwards/backwards randomly by incremental amounts.

Running Deluge-release-7seg108-with-community.bin firmware by user: alter-alter

Video: https://youtu.be/FNYsKK-ZE5w

reproduced by users on the official discord.

I always wanted to have some more randomness for modulation that changes more frequently than the "Random" modulation source which only outputs a new random value every time a note is triggered. How I imagine this to work:

• Add LFO that just outputs a random value every time it is called. This might be a little too jittery to be useful
  • sort of working but more noisy than musical
• Add another LFO that takes a random value and holds it for some time until a new random value is generated
• Explore what kinds of smoothing or restrictions in terms of how far subsequent values can be from each other would be useful
• Now that I understand more about how the LFOs work, next step could be triplet or maybe even dotted LFO sync timings

This is part of the pre-OLED to post-OLED firmware inconsistencies I've noticed after loading the open-source community firmware onto a 7-SEG display Deluge. (See #76, #97, #98, #100, #101)

Browsing through folders with different iterations

Video showing the problem: https://youtu.be/F6mVQvCr_nc

• Display doesn't skip to the end of the title anymore to reveal which iteration (When title is greater than 4 characters). Instead we see the same start of the title when scrolling through different versions.

Extent of issue

This is confirmed with:
[X] Folders
[X] Songs
[X] Kits
[X] Synths
[?] Sample file browsing
[?] Sample folder browsing

Replicable on OLED?

It would be helpful to know if the behavior is the same on the OLED Deluge. Does the OLED scroll to the end of a long title title that extends beyond the display?