Programming



Moderator: multi_s

Programming

Postby oldangelmidnight » Wed Apr 05, 2017 10:02 pm

Hey Scott, I wonder if you'd be willing to talk about the programming behind the Ct5 and 856.
Did you do non-audio coding before?
If I wanted to quit my life and join the Montreal Assembly, what would I need to learn first?
I remember you used to have complicated discussions with Cloudscapes about this stuff.
oldangelmidnight

User avatar
IAMILF
IAMILF
 
Posts: 2485
Joined: Sat Aug 08, 2009 12:17 pm
Location: Northampton, MA

Re: Programming

Postby multi_s » Fri Apr 07, 2017 12:38 am

i guess it depends what you want to talk about.

The short answer is:

it's all done in C using relatively current mcus. C is still predominantly the language used for embedded devices. It is probably teh best language to learn if you are trying to do embedded systems stuff. If you are programming for a pc maybe not, android i think you dev in java and iOS has something called objective C (or swift i think officially).

If you really want to do embedded though my advice would be learn c and learn at least a bit about digital hardware and how it works. then i guess learn about dsp and then specifically audio algorithms. Or do it the other way, learn about dsp, then either find a platform to run on or learn how to make your own hardware. Or find someone who can for you etc.


RE non audio programming:

my formal background has little to do with audio but it was all still mostly all signal processing related. i studied engineering and neuroscience so most of the coding was related to neural signal processing, or in undergrad i did some simpler video processing stuff. this was mostly done in matlab or c++ though, since that is more or less what is/was in vogue at the time in academia. i published some papers where you would have to do simulations/analyze a lot of data so you get pretty good at matlab but it is not a very well designed language imho, it just has a lot of libraries, "toolboxes" as the call them and a huge user base for support so you can test maybe complicated algorithms quickly. last year i had a paper published in an IEEE journal regarding this sort of research but i don't think you can access it without an ieee xplore subscription, but if you are at a university or a library they probably will have access.

You don;t have to go to school to learn about programming or audio though, try coursera, edx, udacity etc. so much free resources and online communities now i almost regret paying for school. (:
multi_s

User avatar
FAMOUS
FAMOUS
 
Posts: 1728
Joined: Mon Feb 15, 2010 9:00 pm

Re: Programming

Postby oldangelmidnight » Fri Apr 07, 2017 3:26 pm

Thanks for the reply.

Is what you're doing fundamentally different from what Strymon, Earthqaker, or Dwarfcraft are doing? To the best of your knowledge? I know EQD made a lot of noise about coming up with their own DSP thing and moving away from the Spin environment. I've read Aen talking about the difficulties of coming up with good code for the kinds of things he wants to do. Would the Strymon, Line 6, Source Audio, etc. models be built on C, fundamentally, with their own proprietary stuff around it?

Do you feel like you're locked in with the hardware you're using? Could you build your stuff with different chips or whatever? Or upgrade as the technology progresses?
oldangelmidnight

User avatar
IAMILF
IAMILF
 
Posts: 2485
Joined: Sat Aug 08, 2009 12:17 pm
Location: Northampton, MA

Re: Programming

Postby multi_s » Fri Apr 07, 2017 3:46 pm

the platform is not that important to me as long as it can do what you want. figuring that out is maybe tricky in a sense but not really. im not sure how we would be locked into anything by developing a few products with a specific chip? over the last few years i have worked with atmel, microchip, st and cypress mcus. it's more about finding the right tool for the job i think. familiarity might speed things up though but since almost everything has migrated to 32 bit arm cores the differences become minor.

i never used spin because it is too limited imho. although it has some perks for sure and is a cool SOC solution.

i can;t speak for what other companies do because i am not knowledgeable as to what platforms they use. most likely it is C or C++ or they use some of the nice GUI analog devices code generator etc but this is a bit to steep for me to get into price point wise atm. i would bet they do it in C but i really have no way of knowing.
multi_s

User avatar
FAMOUS
FAMOUS
 
Posts: 1728
Joined: Mon Feb 15, 2010 9:00 pm

Re: Programming

Postby molokaio » Wed Apr 12, 2017 6:04 am

pretty interesting read!
__________________________________
Live Slow... Die Old!

Instagram: https://www.instagram.com/robzdrone/
molokaio

User avatar
committed
committed
 
Posts: 149
Joined: Wed Apr 07, 2010 6:01 am
Location: ITALY

Re: Programming

Postby Strange Tales » Wed Apr 12, 2017 9:17 am

If you want to peruse other peoples code for the STM mcus, Mutable Instruments has all of their stuff posted on their github page, and 4MS has the SMR and DLD code posted on their github.
木枯らし // 木漏れ日 // 風に綱は戦ぐ

Strange Tales Distro - Japanese Underground Music Distribution in the US
Pedal Demo Videos (WOW!)
multi_s wrote:it's like looking at ascii porn basically, but animated, and french.
Strange Tales

User avatar
IAMILFFAMOUS
IAMILFFAMOUS
 
Posts: 4243
Joined: Fri Feb 06, 2015 7:14 pm
Location: America's Sorrow: New Jersey


Return to Montreal Assembly



Who is online

Users browsing this forum: multi_s and 1 guest


Sponsored Ad. (Please no inflated/repetitive clicking. Thanks!)

Advertisements help support ILF


ilovefuzz.com is not responsible for user-submitted content. Users participate at their own discretion and risk.