Oliver (and anyone else with helpful advice),
I just pre-ordered a Braids from AH, and I am especially excited in learning and “hacking” with the code that went into making all of the synths that come in Braids. Thank you for releasing this as open source!
I am a relative novice to coding, but I have taken a college course in Python, am pretty familiar with MAX/MSP and have been learning SuperCollider recently.
I noticed you mention a few different ways of updating the firmware on the open source page for Braids. Would getting the FTDI Friend be sufficient for being able to change parts of the code and updating the firmware?
I’ve done a bit of DIY soldering and basic EE studying of how circuits work, and am trying to learn to code for music (I recently started reading Designing Audio Effect Plug-Ins in C++ by Will Pirkle along with Cipriani and Giri’s book Electronic Music and Sound Design which uses Max as a way of learning sound design concepts).
If you have any advice to me, as a newb, who is interested in learning how to code and maybe eventually make instruments like you have, I would be very grateful for any advice! I’m hoping Braids will be a great learning tool for me to experiment with and study, as well as, a great instrument to make music with!
> Would getting the FTDI Friend be sufficient for being able to change parts of the code and updating the firmware?
Yes. You can actually do that without any special hardware but it costs you 1:20 of screeching audio every time you want to try your code on the device.
An update through the FTDI dongle takes 15-20s. Through the JTAG programmer, it is only 6s.
Since it is possible to run Braids’ code on your computer, you won’t need that many “trial and error” runs on the hardware to get things to work. Once they work on your computer, the only terrible thing that could happen is that they are too CPU intensive for Braids.
> Python, am pretty familiar with MAX/MSP and have been learning SuperCollider recently.
The programming for Braids is VERY different from these things. Some of the differences:
- This is compiled code so the development cycle is a bit different - trying new things is less direct. That’s why I mostly prototype in other languages (mostly python) before moving to C/C++.
- This is low-level code, not doing much besides arithmetic operations on data… Maybe you could grab a C book focusing on algorithms?
- One thing you’ll have to learn is fixed point arithmetic. I’ve learnt it a long time ago so I don’t really know the good references on that.
- And finally, performance matters a lot!
I think Ill probably go with the dongle, because it is quite a bit cheaper (and just disconnect my speakers to avoid that screeching audio for 15-20s).
This gives me a place to start. Thanks!
Let’s say that if you can write a C program that writes a .wav file on disk with a nice generated sound, without using float or double, you know 90% of what you need to know to do some Braids hacking.
“Since it is possible to run Braids’ code on your computer, you won’t need that many “trial and error” runs on the hardware to get things to work.”
>>is this really how you worked with the previous shruthi/midipal/ambika etc, etc -
- write code, compile.
- functionally test the work on the hardware, and only the hardware.
No testing of the code beyond successful compilation? or is that kind of testing something that the AVR IDE gives you.
> write code, compile. – functionally test the work on the hardware, and only the hardware. No testing of the code beyond successful compilation? or is that kind of testing something that the AVR IDE gives you.
My AVR IDE is a text editor and a command line At the exception of the oscillators code (or anything for which I need ‘subjective’ evaluation) that I prototype offline in python or plain C and then ‘port’ into these projects, I mostly write code and then test straight away on the device. I’m kind of disciplined when it comes to code so it mostly works right at the first run.