Custom DSP objects guide?

#1

Hi all, I know this point has been mentioned before but I'd like to stress it again in an extra topic to increase visibility and encourage more people to join in. wink

Axoloti is an absolutely great project (congrats, Johannes!) and for me the final killer aspect is the possibility to add your own custom dsp objects. (Personally I'm dealing with physical modeling and simple amp modeling kind of stuff, but I'm sure there are so many more very individual and specific algorithms people would want to run on the Axoloti Core hardware, which can't be realized well, or not at all, just by patching, without writing actual C/C++ code.)

Therefore I'm sure I'm absolutely not the only one who would appreciate a guide on adding your own custom DSP objects. I was very positively surprised how easy it was to add a dsp object by copying and modifying an existing .axo file but I'm sure a quick dedicated guide would help the Axoloti community to be more productive and grow. Some aspects which spontaneously come to my mind, to include in a guide on custom objects are:
* Correct generation of UIDs and SHAs
* Data types, fixed vs. floating point computation
* Best practices for structuring code with includes, inline directives, etc. ...
I'd like to encourage everyone interested in this topic to add her/his questions.

I totally understand that writing a guide to custom objects is currently not the top priority for those involved with getting Axoloti to take off. But maybe a quick summary of some main points could still be done. And anyway it would already be good to know if any such documentation is planned and when we might expect something like this...

#2

If someone starts to write such a guide (sorry I don't have time), then I will move it to the user guide section. ( and make it a wiki page which means others can edit)

So my suggestion is , start writing with sections , and then others can add parts in the comments, which you can then edit into the main text.

(Tip: best way to get things done is to do it yourself smile )

#3

some code examples are here: http://www.musicdsp.org/showmany.php

though they need to be ported to axoloti smile (for which a tutorial can be usefull)

#4

A post was split to a new topic: Creating AXO objects

#5

@alex, Ive moved your guide to a new topic in the user guide section...
I've closed it so that we don't get a discussion on it (here would be a better place for that)\
Ive also marked it as a wiki, so editing should be possible by all (over than newbie posters)

let me know if you are unable to edit it

one small comment, you are missing the midi handler section in the code.

a couple of suggestions:

  • do as one post, discourse is not great at linking topics, and we don't want lots of small topics in the user guide section. (the markup language is not too bad for section heading etc)

  • id suggest an 'intended audience' section, so that the scope can be defined/limited.. i.e. no point in trying to teach xml/c/c++ in that topic. we could build up a 'recommended reading' section for interested people to go to... I think there were some books recommended last time this topic came up.

a more 'general' point, the intention is the object editor will allow this all to be done in the future without the need for xml or knowing about uuid etc

#6

oh, forgot to say... most importantly ... thank you for taking up the baton smile

#7

thanks.
I wanted to gather some response/suggestions in this thread before making it into a new topic, but lets see what happens...

The 'intended audience' is probably from absolute beginners to experienced coders.
Even an experienced C coder probably is like 'wtf is this? ' when they first look at an .axo file.
Since there are a few weird things in the xml I think it is necessary to explain some basics. But there is no point in pointing to an XML manual for understanding .axo files, since all that is needed to know (for this use) can be explained in a few lines.

What I want to avoid is explaining DSP techniques, because there are a lot of sources out there already. But perhaps an example explaining how to turn some existing C code into an Axoloti object would be a nice starting point for a more advanced tutorial.

About the object editor: personally I don't like to use some java gui, so I don't think I'll be using that (no syntax highlighting, too much clicking around ).

#8

I think rather unlikely, i certainly found the structure pretty obvious... the only 'unknown' was the types and encoding scheme... (most programmers these days have a pretty good understanding of things like xml/json etc)

really, the #1 suggestion is simple ... go look at some objects that you already know what they do, what parameters/inlet/outlets they take, then go look at the axo file.... then go look at a few more.
you will soon start to recognise the types etc... and after a while see how they get encoded/decoded.
but frankly, thats the pretty obvious way to understand any new system, and this stuff is not rocket science smile

Funny, thats the area I think many coders might have a lot to learn... also the difference between coding on a 'computer' vs micro-controller. but, as you say there are plenty of books out there on this.
the one thing i didn't recognise initially were the ARM instructions, SMUL etc, but if you google those the info is pretty good.

I agree with you on that, just saying the direction @johannes was going.
(its also good for looking at existing objects, as its quicker than finding the axo file in the filesystem smile )

however, now doing the push stuff, I've noticed actually i wouldn't mind, since all i do in the axo file is call a function, Im not writing any code in the axo file itself, all the code is in a C file ( i guess i might if i was writing trivial objects)

it may also be worth pointing out, don't edit the 'factory' axo files... even if you want to contribute code changes. the reason is, they are generated from java, so the changes need to be made there.

#9

The object editor can be improved, I agree it lacks quite a few things for comfortable coding: undo, indenting, syntax coloring, bracket matching. Perhaps RSyntaxTextArea could be integrated. But that does not help if you're a fan of emacs or vi. For prototyping, I often edit in a external editor, and copy paste it into the object editor currently.
When custom layouts are added, allowing objects to define the location of inlets, parameters etc, a visual editor is hard to avoid, or you'd need to estimate/compute coordinates...

Explaining DSP techniques, it is a deep subject, I do not want to replicate the >15 years of music-dsp mailinglist discussion here...

The quality of this archive is really mixed, use with insight and care!

#10

I can't choose the category UserGuide , so unable to save. (will try to use it wisely wink )

#11

Can we use "preformatted text" for literal code, rather than editor screenshots? Makes it more maintainable.

#12

test

<params>
   <frac32.s.map name="value"/>
</params>

yes... it works. wrap it between

#13

@alex, try now.

you can also add blocks of code, by indenting four spaces.

EDIT: ah, but the 3 backquotes gives you syntax colouring , cool smile

#14

@thetechnobear
yes, works now.

since we're discussing layout now, I noticed the wiki topic posts have a light blue background. Nice, but it is the same colour as the code/blockquote .
Perhaps choose something else for 

.wiki .topic-body {    background-color: #f4faf4;}
#15

discourse supports colour schemes, so easy enough, just need to check its 'default' doesn't change the look too much ... so will do when I have enough time to deal with any issues it may introduce.

#16

Here it is light green, and quote/preformatted text has a light grey background. Weird.