Questions for Q&A #2 (June 18, 10:30am, CEST)

[ian-jorgensen]

Please ask questions for Q&A 2 here.
Please have watched Q&A #1 first: https://www.youtube.com/watch?v=4uPaIEWg02s

[weavermedia]

Can you talk about the intended firmware options for regular users? My understanding is that there will be the official Synthstrom build and a separate (and likely quite different) official community build. But will there also be (potentially many) unofficial builds from different developers, each with their own specific feature implementations? Are there any plans to manage these 'off-world' builds?

[weavermedia]

Should we be adding feature ideas as issues? Maybe there could be an issue template with a framework for submitting a feature idea? Might be good if submitted features had at least a full description and some high level implementation details.

[litui]

I can answer this beforehand as it's been answered before. Feature ideas are for the forum, and developers will be encouraged to peruse suggestions given there for popular ideas and things that seem interesting to work on. Issues in GitHub are ideally reserved for work-in-progress enhancements (which are perhaps better stored as Draft Pull-requests), documentation fixes, and bugs.

[weavermedia]

Excellent. So sounds like we still need an issue template that discourages feature idea submissions as issues and directs people to the forum instead.

[litui]

@weavermedia totally. There's a draft PR for a CONTRIBUTING.md guide that is a file Github pays attention to once it's in the community branch. Folks submitting PRs and Issues should see this document linked at the time of issue creation once it's in place. #38

[weavermedia]

Seems like the 16 Levels feature by alter-alter (https://github.com/alter-alter/DelugeFirmware) is getting a lot of traction.

• What is now the process of getting this suggested as a community feature?
• Should the dev just submit a pull request?
• Is there any mechanism for tracking support and enthusiasm for new third-party features?
• And is that even a factor in deciding which features are merged into the community repo?

[aopsyche]

I think you've asked important questions here that the community will need to find answers for. In fact, a few of these questions have already been addressed by the community, especially in the .md docs within the repo. However, Synthstrom has expressed their desire for the community to dictate it's own management, and likely have very little further input on the sort of questions you're asking. The questions selected for the last q&a were more about technical details in the codebase.

[weavermedia]

@aopsyche I'm asking these questions of the community, not Synthstrom. Jamie and Aria were both present in Q&A #1. However if the Q&A is meant to be technical I'll ask somewhere else, maybe just bubble them up as a question in Discussions here. I found the Q&A a little heavy on the low-level implementation side and not so much on the community side. Maybe there should be a community Q&A where Jamie and Aria take the lead and talk about these issues.

[aopsyche]

I agree with all you've said, and perhaps i misunderstand the intent of the upcoming q&a livestream. Just a heads up that a lot of these concerns may be better pursued through other avenues, but who knows? The fact that we're not totally sure if those are appropriate questions for this discussion highlights the importance of your questions!

[litui]

The 16 levels feature seems really cool! I haven't tried it myself yet, but it looks amazing.

The developer has not (yet?) submitted a pull request to have it added to community. I don't have insight into why, but that would, in my opinion, be a gracious first step. While the code is perpetuated under the GPL and can be taken and re-integrated however we would like, it's generally considered bad form to do so without at least talking to the author about their plans, whether the code is "finished" enough for them to be comfortable with it being re-integrated, etc.

Then reviewers (not suggesting this is just myself or @jamiefaye by any stretch) should evaluate it for feature-completeness, stability, configurability, compatibility, and other community-decided criteria for what gets accepted into the community branch.

There are community decisions to be made before that makes sense, again in my opinion, because there currently is not a well-defined vision for the community branch or vision for how new features of this magnitude get integrated.

There's also nothing wrong (again in my opinion) with third-party features or firmware builds persisting in their own forks and branches as long as the authors want them to do so. Nothing says all features developed for the Deluge can or should be brought back into the community branch.

[weavermedia]

@litui @aopsyche Could we have a community-specific Q&A? Just to discuss some of these points? No low-level technical stuff.

[weavermedia]

Should the community issue a statement about installing third-party (non-Synthstrom, non-Community) firmware? I wonder if there should be some managing of expectations for regular users.

Some folks are confused about how to install, what they're installing, how to roll back if required, safety concerns, etc.

[litui]

Work to make this process more safe for users, especially of older Deluge models susceptible to certain bootloader bugs, is currently underway by Rohan et al.

I think, and have seen this be the case in other projects, that it makes sense to explain about the basic process, but to not outright offer support for other firmware builds. Instead, it might make sense to focus on the community branch as a stable, safe, reliable build and issue a warning that other builds are "at your own risk" to some extent, and let those branches and the communities that will inevitably rise around them support their users similarly to provide reassurance and reduce risk. In my experience, there is only so much responsibility the community can or should take on.

[weavermedia]

Agreed. I'm definitely not suggesting that the community take on responsibility for any third party stuff. Just that it might be more reassuring to regular users to hear the official stance from the community leaders.

Along the lines of exactly what you said plus some other salient facts like:

• The community build is the only official build
• Other builds are installed "at your own risk"
• All third-party firmware (so far) is built on top of the base community code so will have ll the official features plus more
• Deluge can only load one firmware at a time
• Any firmware can be reinstalled at any time but projects may not work as expected
• Some mention of the potential bootloader issue for older Deluges

[PaulFreund]

Can we get the source code of the boot loader once it is finished? I don't think there are plans to overwrite or provide the bootloader itself but there are some ideas for a second stage bootloader process where the code would be really useful for. One example is showing a list of Firmware Files on the SD card and loading the selected one directly to memory without needing to write the flash.

[weavermedia]

Off the topic of the boot loader but on the topic of multiple firmware choices - is it possible we'll get in a situation where songs will only work with the firmware they were created on? When song uses a particular feature that isn't present in the currently loaded firmware.

[PaulFreund]

While this is possible I hope we can navigate around issues like that. I used your question as input for PR #56 and added some requirements regarding user file compatibility 8088c52

[weavermedia]

Just noticed 10:30 CEST is 4am here (PDT, Los Angeles) 😭 Is there any flexibility on the time of the Q&A?

[PaulFreund]

I'm from Europe and last time I was not able to join so I find it fair to enable other timezones 😅 Not sure there is something that works for all time zones.

[weavermedia]

Yes, indeed. I guess I don't mind missing it. I'm more interested in the community side than the low-level technical discussion and since Rohan will be at this one it makes sense to drill him on as much technical details as possible! 😀

[alex-r-t]

On a technical level, how are the parameter values between cloned clips related? Which ones share a state (e.g. wave type) vs. not (e.g. Cutoff Frequency)

[alex-r-t]

How is the Stutter effect implemented?

[alex-r-t]

For parameters that can't be mapped to MIDI and/or assigned to a gold knob (saturation, for instance), are there technical reasons why we should avoid attempting to implement that?

[alex-r-t]

How is the Drive effect of the Low-Pass Filter achieved?

[alex-r-t]

Are there any negative effects (e.g. battery life, performance headroom, etc.) associated with a higher LED refresh rate for the grid and buttons?

[alex-r-t]

When it comes to modulating parameters with other parameters, which ones have a multiplicative relationship vs an additive one?

[alex-r-t]

How is pitch detected in samples?

[alex-r-t]

When you load a normal (non-wavetable) sample as a source for the wave table oscillator, how is that approximation/interpolation done?

[alex-r-t]

How is the Analog mode for the delay section achieved?

[alex-r-t]

What are the conditions under which the "undo chain" will break/reset/clear?

[alex-r-t]

For the gold encoders, there doesn't seem to be a way for those to act in a bipolar way when controlling bipolar modulation parameters. Is this a limitation in the hardware, the firmware architecture, or is this something that can we could address in an open-source patch?

[alex-r-t]

What are the technical details behind how modulation/MIDI CC data stored in a clip?

[alex-r-t]

When one parameter is being modulated by another, what resolution is that modulation occuring at?

[alex-r-t]

When a parameter is mapped and controlled by a gold encoder, what resolution is that encoder affecting that parameter?

[alex-r-t]

When MIDI data is received by the Deluge, is that data smoothed or interpolated in any way? What about MIDI data sent from the Deluge to another device?

[alex-r-t]

Would Synthstrom Audible consider open-sourcing the hardware at any point in the future? If not PCB layouts and a Bill of Materials, what about CAD models for the side panels and enclosure?

[bfredl]

I've been working on loading executable code as additional "modules" on top of the firmware. A problem for this is managing the coherency between the L1 data and instruction caches, as the ARM has a Harvard architecture for the caches.

The source tree does contain some driver code form Renesas for cache management, and I would expect the the following sequence to work for executing loaded code:

    // after loading code into a buffer in ram
    L1_D_CacheWritebackAll();
    L1_I_CacheFlushAll();
    // now it is safe to execute the code

However, executing either of these functions causes the deluge to just hang.
As a primitive workaround I have used, just doing a lot of memory accesses in between (to force writeback of the caches) works to execute loaded code correctly, but there should be a better way to do this.

Perhaps Rohan has some useful insight into the cache management of the RZ/A1H? Some code in the bootloader could relevant here, as been mentioned in this other question before: #36 (comment)

[alex-r-t]

Is the requirement to have the Deluge plugged into wall power to function as a USB host a hardware limitation?

[weavermedia]

Just to clarify, it doesn't need to be wall power. It just needs to be powered from the 9v DC input jack. This means you can power it from a USB battery pack or similar and it will function as if it was mains powered. I thought I read that it was a supply current limitation.

[alex-r-t]

Yep! Sorry, I should have clarified that I meant DC power - I use a myVolts cable all the time. Thanks for bringing that up 🙏

[weavermedia]

On the topic of modulating the sample start point. Is this currently limited by the fact that samples are streamed from disk during playback? To modulate the start point would the whole sample need to be loaded into RAM when the song loads?

[0beron]

How does the Session and/or playbackhandler achieve scheduling things to happen in the future? Specifically clip launching in a similar way to the scheduling of sections. What should I be aware of if I want to schedule a clip to start at a point in time in-between a section pad press and the longest clip length when the sections will change?

[alex-r-t]

What kind of interpolation (if any) is occuring when changing wavetable position in a synth?

[suivaht]

I am interested in creating alternative play directions for note rows (specifically a random step mode). I saw something in the code specific to reversing a note row versus pinponging it... Any tips/concerns I should be aware of when pursuing this, and related to that where are the menu items for playback direction located? Thanks in advance!

[m-m-adams]

In Q&A #1 Rohan mentioned a quick method of estimating CPU usage by playing simultaneous synths with a long release and watching how many voices there are when it gets culled. In doing this I've noticed that the 12dB filter starts culling with less voices than the 24dB filter - is there a catch to be aware of when using this method to estimate CPU usage?