controller patches are added to an existing patch... on compilation.
to use we simply create a new 'controller object', the easiest way to do this is to create a subpatch
then we just reference this object in the preferences (file->preferences)
example:
so in this example,
a) I've got a new directory in my search path , where I keep my custom objects.
/Users/kodiak/Documents/axoloti/objects
b) Ive then created a sub-directory in that directory called controllers, where I can store my 'controller' objects,
c) I then created a sub-patch called test.axs which I save in that directory
i.e. its stored in
/Users/kodiak/Documents/axoloti/objects/controllers/test.axs
d) now I have an object called 'controllers/test' which I could explicitly use in patches, but instead I'm referencing as a controller object in the preferences so its added to all patches.
e) as with all 'custom objects' if you add a new one, you will need to use 'reload objects' from the file menu (or restart axoloti)
to test is simple,
simply create a blank patch and then 'go live' and see if the functionality is included.
when a patch uses your controller object you will see a message in the console log, similar to
"Using controller object: /Users/kodiak/Documents/axoloti/objects/controllers/test"
if you dont see this, it probably cannot be found, so check the paths and names, and also try 'reload objects'
then you can build you normal patch, then when you go live , the controller patch functionality is included.
the reason its named controller patch, is really the 'intended use',
(though it could be used for any functionality you want to default)
imagine you want to have it such that for every patch you build, you want to have program changes switch a presets.. you could add this functionality as a controller patch, so you don't have to add the subpatch to every patch you build. (and more importantly, if you download a 3rd party patch it would work for that too without having to change their patch)
its 'limitation' is it cannot interact directly with the 'main patch', so you would tend to use midi outputs (or I guess audio as you are doing) ... this is intentional, since if it has wires, you would then have to wire it into the main patch, which is what Im trying to avoid, since if you do that you might as well use a sub-patch.
btw, the in/out ... there is a much better way to do this, that I want to add... the hardware codec has a built-in mixer, which allows input to be copied to output, we just need to add support for this in firmware (or an object) , this would mean the CPU would not have to get involved with doing this audio thru.
(important for FX patches, where this would act like a 'mix')
