synthstromaudible / delugefirmware Goto Github PK
View Code? Open in Web Editor NEWHome Page: https://synthstromaudible.github.io/DelugeFirmware/
License: GNU General Public License v3.0
Home Page: https://synthstromaudible.github.io/DelugeFirmware/
License: GNU General Public License v3.0
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.
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:
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 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
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)
Video showing the problem: https://www.youtube.com/watch?v=iq0kG6glywE
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.
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.
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)
Video showing the inconsistency: https://youtu.be/PXD9Psp94UI
This is confirmed with:
[X] Folders
[X] Songs
[X] Kits
[X] Synths
[X] Sample file browsing
[X] Sample folder browsing
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?
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?
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.
Tested with community build on 7SEG https://github.com/SynthstromAudible/DelugeFirmware/actions/runs/5478105923
At this point the SVF filter is in default with MIN resonance and MAX cut-off,
NB: the feedback can be killed by either:
This may be relevant to #105
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 great to save the brightness settings permanently.
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:
Side goals:
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.
A few possible options for implementation:
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:
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
Stress test of the Deluge comparing FW 3.15 and FW 4 (community)
Testing setup
Test
Result:
all files can be found here:
https://drive.google.com/file/d/1-AR-5WxnJaHFXip0Gsh2bOirj1FZE5I0/view?usp=sharing
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.
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
N != 12
N = 12
being much smaller than N != 12
owing to noteWithinOctave
being quite prevalent within voice.cpp
.Root note is C, offsets follow Pythagorean tuning.
Key | Value |
---|---|
Root Note | C |
C | +0.00 |
C# | -9.78 |
D | +3.91 |
D# | -5.87 |
E | +7.82 |
F | -1.96 |
F# | +11.73 |
G | +1.96 |
G# | -7.82 |
A | +5.87 |
A# | -3.91 |
B | +9.78 |
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.
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.
A second USB midi upstream port should be enabled to separate MPE zones from normal midi channels. I am happy to work on this
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)
Video showing the problem: https://youtu.be/Vx7kILI1NwQ
This is confirmed with:
[X] Song iterations
[?] Synth iterations
[?] Kit iterations
[?] Folder iterations
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
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:
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.
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:
./dbt dbt-build-debug-oled dbt-build-release-oled
etc.)
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:
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.
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
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.
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
@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:
HAVE_OLED
to mean that we're using the OLED UI, to minimize churn in the upper/UI layersDELUGE_DISPLAY
(bikeshed name) similar to DELUGE_MODEL
which is used by the lower layers to switch between physical OLED and 7SEG output.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.
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.
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.
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.
From a discussion on Discord earlier today: https://discord.com/channels/608916579421257728/1118654563596128336/1121185820854980678
In the waveform editor, the following shortcuts should work:
Steps to reproduce:
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.
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.
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.
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).
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.
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).
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:
I also disabled OLED text scrolling because i find it incredibly distracting. I simply commented out a line in View.cpp.
Suggestion:
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.
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:
Using 7SEG release bin from latest community build https://github.com/SynthstromAudible/DelugeFirmware/actions/runs/5359807075
[oFF ]
[28t ]
[4th ]
[2nd ]
[6th ]
[th ]
[th ]
[nd ]
Note that (select, scroll right) the first few options look OK. But eventually it'll loop around to the newer options, as above.
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:
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.
This pertains to #17
Would like this feature to be toggle-able (ON/OFF) in the Community Features Menu.
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.
This would be an automated way of recording each individual track in a song. I'd imagine the process as:
[song]-[track].wav
.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:
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:
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!
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).
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.
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.
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
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)
Video showing the inconsistency: https://youtu.be/zBvPcSGLN04
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)
It would be helpful to know if the behavior is the same on the OLED Deluge.
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.
(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.
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.
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.
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.
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)
Video showing the problem: https://youtu.be/F6mVQvCr_nc
This is confirmed with:
[X] Folders
[X] Songs
[X] Kits
[X] Synths
[?] Sample file browsing
[?] Sample folder browsing
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?
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?
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)
Alternatively:
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.