Questions for Q&A #1 (Wed June 7th, 7pm)

[ian-jorgensen]

On June 7th we'll be hosting the first of two video Q&A events. Once you've had a moment to look through the code and documents, please feel free to ask any questions in this thread. We'll gather those together and answer them at the beginning of the Q&A.
The session, featuring Rohan, Jamie and Aria (hosted by Ian) will be streamed on our YouTube channel, https://www.youtube.com/SynthstromAudible - at the end of the session you'll be able to ask questions via YouTube chat - although you must be a subscriber to the channel to ask (so please do so in advance if you think you might ask anything).
The Q&A video will be archived and made available to watch after initial screening. I'll link it here afterwards.

[ian-jorgensen]

Re-sharing a question that was asked in a thread that was deleted when we had to move the branches around:

"I'd like to hear about the 'clusters' that I see in some sample playback and timestretch code.
is this is just a clever name for audio buffer lists? or maybe connected to an underlying strategy for playback?"

[sapphire-arches]

2 sort-of related questions:

• Can we get a high-level overview of what hardware is present and how it's connected? I fully understand not wanting to release complete schematics but a diagram of e.g. the various I2C busses and what's on them and at what address would be handy.
• Is the hardware capable of USB High-Speed (480mb/s) operation?

[aopsyche]

Are there any further insights on debugging in the future? Will there be a development model sold? Does synthstrom have any interest of hosting a debug server where users could access the appropriate hardware remotely, possibly with paid subscription? If not, would this be an effective solution for the community to pursue?

[aopsyche]

To generally expand on these questions:
Access to the hardware for debugging seems to be the most obvious limitation to development at present. I'm sure this is actually a useful barrier to entry for deluge development in this initial phase of opening the code, but what are the options, possibilities, and intentions in regard to debugging in the future? Does Synthstrom have interest or ability in making debugging more accessible, and to what extent?

[litui]

To generally expand on these questions: Access to the hardware for debugging seems to be the most obvious limitation to development at present. I'm sure this is actually a useful barrier to entry for deluge development in this initial phase of opening the code, but what are the options, possibilities, and intentions in regard to debugging in the future? Does Synthstrom have interest or ability in making debugging more accessible, and to what extent?

I can answer more in depth during the Q&A but just wanted to make sure you're aware of https://github.com/litui/delugeprobe as well as the DIY Hardware Debugging Guide I put together for launch. Accessible debugging is what I'm all about =)

[aopsyche]

I can answer more in depth during the Q&A but just wanted to make sure you're aware of https://github.com/litui/delugeprobe as well as the DIY Hardware Debugging Guide I put together for launch. Accessible debugging is what I'm all about =)

Yes, I plan on going to Microcenter this weekend to get parts for your DelugeProbe! Thanks for this work in getting a low cost option figured out and making these guides! However, i feel that hardware modification of the deluge is a barrier that will significantly hinder developers.

I do have a few more related questions (pardon my ignorance here, i presume the answer is an obvious "no" to all): will it be possible and legal to emmulate the deluge hardware for testing? Any similar solutions? can a suite of unit tests be built that is considered a capable alternative to in-the-box testing?

Thanks again, and i look forward to the q&a!

[m-m-adams]

That's a great question! Someone could work on a qemu setup for virtual debugging

[x3003]

Is the hardware capable of doing midi 2.0 ?

[MrBlockers]

I've noticed references to past commits in a comment, but I am guessing they were made using SVN or some other VCS software besides git. I am unfamiliar with e2 studio so this may be a silly question if the history is somehow stored within the project files. Is there a way to access the old commit history of the codebase?

[m-m-adams]

1. Could we get a demo of the model stack and how to actually interact with it, or references to places in the code where you feel it's done well?
2. In the driver code, which parts were written vs provided by Renesas?
3. Are all the VA waveforms wavetables under the hood, and if not where in the code are they implemented?
4. Could we get a walkthrough of how the osc sync implementation works? I don't recognize it and I'm pretty curious

[entzmingerc]

Adding onto question 4, I'd love to hear a thought process of adding a feature! When you added a feature, say osc sync, how did you test it? Did you measure "CPU load", memory usage, and/or turn knobs until it seemed good?

[alex-r-t]

Some of these are primarily for Rohan, but they're pretty general for the most part. Hopefully it's not too much for this first go:

• What are some of the overarching design philosophies and guiding principles you'd like to see in the community codebase? e.g.:
  • How synths and functions map to the shortcuts in the grid, and how new features should respect the shortcut layout
  • How important a priority it is to make knowledge and muscle-memory "transferrable" for users coming from the "official" firmware
  • Layout of menus and navigation, max menu depth, button combos, and push+twist encoder behavior
  • Using the grid as a 8x128 display
  • etc.
• What's the deal with fonts? I tried using this converter mentioned in the code, but generated C code was in hexadecimal (vs. binary in the existing firmware), rotated 90 degrees, and seemingly displayed in the wrong order. Any ideas?
• What do you see as the biggest untapped aspects of the hardware/largest areas of potential? Are there certain aspects of what the Renesas chip or other components can do that haven't been fully realized yet?
• What are the biggest limitations or potential "gotchas" that folks who want to contribute should be aware of? Are there rabbit holes you've found yourself down that we should avoid?
• Are there certain features you think the community should collectively work on first?
• Are there certain features you've always wanted to implement, but didn't have the time or knowledge to accomplish by yourself?
• What do you want to work on next?
• How do you feel about how the open-source effort is going so far? Any highlights or things to look out for?

[litui]

A couple of questions to prompt discussion, if we get around to it:

• is anybody looking into or should we be looking into a code of conduct for those participating in development efforts?
• will Synthstrom be providing the ability for Deluge owners who are not savvy with the soldering to have their systems modded with an external debug port?

[phfalk]

I ran into an issue while trying to convert a makefile that was produced by e2studio into a cmake file to be able to build on Linux with the standard arm-none-eabi toolchain. After getting the build to work, I tried flashing the firmware binary and the Deluge rejected it and said "Found firmware file does not contain valid firmware". Could you quickly explain what checks are done to verify whether a firmware file is valid?

[chrisbc]

the deluge has already undergone massive transformation (I'm a relative noob, only hear since 3.15) but I can see tracks in the codebase :).

I'd love to hear from those who've made all this happen about their triumphs (those aha moments!), but also their frustrations along the way. And in particular, do they see any opportunities to break some shackles in this Community edition that were not available otherwise (backwards compatability etc).

How might the community can manage the concept of dropping support (eg for old song files etc) without breaking apart the user group.

...all the best, Chris Chamberlain (Masterton, NZ)

nb I think @alex-r-t covers a lot of this too in his questions