Firmware v18.03 - Lines of Code

- Cliff: As far as DSP programming goes: C and C++ ...

Thanks for posting the information. That's the kind of thing I was looking for. Still curious about the number of lines of code though. Makes for great lecture conversations and it makes student's realize what's involved in the development of a product like the Axe-Fx. :)
 
Wow, thanks for those quotes about what kind of programming goes into this. I spent 4 years recruiting high level embedded developers for companies like Qualcomm, TI, ST Micro etc and very very few venture into the unique uncharted territories like cliff has.

Additionally, the part about building OO functionality into C is extremely impressive.

We all knew cliff was a product genius and a hell of an engineer but now we know a little bit more about just how much engineering prowess he's brought to this product.

One of a kind.
 
It's been decades ago since debugging of code could tell the competitors one little fart about how to look into the whole of a great piece of gear.
 
Wow, thanks for those quotes about what kind of programming goes into this. I spent 4 years recruiting high level embedded developers for companies like Qualcomm, TI, ST Micro etc and very very few venture into the unique uncharted territories like cliff has.

Additionally, the part about building OO functionality into C is extremely impressive.

We all knew cliff was a product genius and a hell of an engineer but now we know a little bit more about just how much engineering prowess he's brought to this product.

One of a kind.

Couldn't agree more!

I started doing this kind of thing in school, back in the early 80's. My final project was a Motorola, 8-bit microprocessor [6808] based security system. I had to develop all the decode logic for the RAM, ROM, PIA, microP, keypad, etc. then design and build the sensor circuits. The electronics was all wire-wrapped on perf. board. I remember having to write the assembly code by hand, looking up the mnemonics in the book, then hand compile it, copy it onto an 8" floppy disk and then burn the hex code into the EPROM with an EPROM programmer. If you made a mistake, you had to stick the EPROM under a UV light for 20 minutes to erase it, then re-program it.

It's amazing how far this type of development has come in such a short time. To see what Cliff has done with it, is beyond impressive!
 
It's been decades ago since debugging of code could tell the competitors one little fart about how to look into the whole of a great piece of gear.

What the hell do you keep yammering about? I teach embedded programming and I like to present the student's with information/facts from relevant, revolutionary products, like the Axe-Fx. I also learned to play the guitar, late in life, so it's great to be able to combine my career related interests and my personal interest/hobby. I didn't ask the questions I did to try and...

" debugging of code could tell the competitors one little fart about how to look into the whole of a great piece of gear. "
 
What the hell do you keep yammering about? I teach embedded programming and I like to present the student's with information/facts from relevant, revolutionary products, like the Axe-Fx. I also learned to play the guitar, late in life, so it's great to be able to combine my career related interests and my personal interest/hobby. I didn't ask the questions I did to try and...

" debugging of code could tell the competitors one little fart about how to look into the whole of a great piece of gear. "

I rest my case. Did you by any chance think that anyone could or would answer the question...
And even if you could debug into so many lines - your students would have to sit for two years before understanding even the tiniest bit of code.
I would rather learn them about barebone computing, which 99% of your graduates will have more chance to making an earing out of.
 
Not sure if there is a simple answer to the first question...but how many lines of code are in the v18.03 firmware? What language(s) is it written in? How many programmers are there?

Thanks

I have it on good source, there's at least 7 lines, all in Latin.
 
- Cliff: As far as DSP programming goes: C and C++ are very similar however you typically have to resort to some amount of assembly programming to get the algorithms to run efficiently. / The Axe-Fx was programmed in C and assembly. Assembly is still a necessary evil to get the most performance from a DSP. The C portion of the code was written object-oriented which C doesn't support inherently but was done using structs for objects. A little more difficult to program than C++ but results in smaller binaries and therefore smaller memory footprint. Like I said before, modeling is very difficult and I could fill a book on the subject. I recommend starting with delays and filters as these are the foundation for everything else. The effects section of this website is actually a pretty good resource. Diving into modeling first is like trying to build a house without ever having used a hammer or saw. There's very little published on the subject of modeling. I've filled three engineering notebooks to date but haven't published anything. The only guy I know doing any sort of publishing on the topic is Julius Smith from Stanford. To do it properly you need to understand the maths. The classic text is Digital Signal Processing by Oppenheim and Schafer. There are several other excellent texts on the subject. Understanding the DFT and z-transform are crucial. Don't listen to people telling you to use anything other than C or C++ (and Assembly where necessary). These are the de-facto languages for a reason. Things like ChucK and Nyquist are inefficient, incomplete and immature. They are useful for trite tasks but totally unsuited to serious applications. Matlab is good and I use it all the time for algorithm testing and visualization but it doesn't really port well to C/C++ and the Matlab compiler is incredibly inefficient since Matlab treats everything as doubles.

- Cliff, TGP: There's no question that modern compilers are much improved. However, a compiler doesn't understand that the fastest algorithm isn't always sonically the best. Finite-register length effects are something very few programmers understand and the order in which you do things has an effect on the resulting audio quality. Most programmers just think "it's floating-point, I don't need to worry about register length". Furthermore I've yet to see a DSP compiler that can match hand-coded assembly in performance. This is likely because DSPs are inherently short-pipeline devices with limited branch prediction. I don't do much general-purpose CPU programming so I have no comment on the efficiency of modern compilers for those devices. I have done extensive tests on the DSPs we use and the hand-coded assembly is always faster, smaller and better.

- Cliff, TGP: What I do is write the framework and UI in C (I actually use an object-oriented version of C that I developed. It has the OO aspects of C++ but results in a smaller footprint and faster execution). All low-level functions like filters are written in assembly and called from the C framework. The actual user input is handled by a separate microcontroller. Register length is the length of the registers in bits. IEEE floating-point is 32 bits and most floating point math is done at this length. Double-precision is 64 bits but takes much longer so it is rarely used. Single precision is fine if you understand how to use it properly. F.e., if you add a large number to a really small number the really small number is essentially lost and the audio quality can suffer. Consider y = a + b - c. Most people would add a to b then subtract c. However if b is really small the proper way to do it is subtract c from a then add b. This is a grossly simplified example but illustrates the basic concept. A compiler has no way of knowing the relative magnitudes of the numbers and therefore can't make a decision on how to commute the operands. How does DSP power of Axe, 11R, Pod HD compare? - Page 3 - The Gear Page

- Cliff: I've yet to find a compiler that can come anywhere even remotely close to hand-optimized assembly. Typically an assembly routine will run at least a few hundred percent faster. The downside is that assembly is a bitch to write and debug. I'm amazed though at how bad many programmers are at optimizing even high-level code. Simple things like moving divides outside of loops or reducing memory fetches they don't even understand. The speed of modern processors has made programmers lazy. We're using 3 GHz computers with 2GB of RAM that run no faster than an old Apple Mac for many tasks (much of the Mac code was written in assembly). Software bloat has become a real problem IMHO. I've spent countless hours testing functions to improve throughput and reduce footprint. Something programmers no longer do. All they care about now is meeting the spec's and moving on to the next project. I suppose optimizing code isn't very glamorous or rewarding though.

Whos that in the what now?
 
This made me cry

So you've seen what a single line of lisp looks like I see.

I'm a developper and have a developer friend who used to always try selling me on that language. I'm not sure how I could have possibly been less interested. I couldn't get past the 14 sets of parenthesis per variable.
 
Last edited:
Back
Top Bottom