Help with controller object

#1

Hi. I know it has been dealt with many times but after having read through the relevant threads I'm still unsure about how to reference the controller objects. I'm even unsure as to whether controllers can be used this way.

Here is what I want to do:

-I want a selectable oscillator bank subpatch, so I can change oscillator types in my synth without having to load an entire new project.
-my synth has three oscillators, so I would like the bank to be available to each one.
-I want to control it by midi, allowing to scroll through the different oscillator types.
-I created this folder: Users/me/axoloti/controllers/oscillators and added it to my preferences.
-then the idea is to have a different subpatch, one for each oscillator type, and when I press a button on my controller the oscillator type changes.

Will this work or am i just wasting my time?

am I correct to understand that there can only be one controller object per project?
I would like at least three different live-selectable subpatches, one for each oscillator.

If it is possible: What should my file structure look like?

I think I would need three controllers: OSC1.axp, OSC2.xp, OSC3.axp.
each of these would reference the same "oscillatorbank" folder of subpatches.

It is really abstract for me, sorry... I can't yet wrap my head around it. Sorry if I am completely off...

Thanks you are so helpful!

#2

I don't think you need to use controller object for this.

If you want to do it the smart way and save dsp and memory, I would say the best way would be making a wavetable with the osc types you need and then load them into a table.

Let's say you want saw, sine, square and triangle. You can create those 4 waveforms in Audacity, lets say you want each waveform to be 2048 samples long. Once you made the waveforms, you cut them so you only have ONE cycle of each. Once you done that you change each of the waveforms size so they are 2048 samples long. You do that by using the effect called "change speed". You can set the length of the waveforms with sample precision, so you set it to 2048, if that is the size you want.

Then you copy the 4 waveforms, which are now all 2048 samples into the same wavefile, so you end up with a file/wavetable with the 4 waveforms that are 8192 samples long. Then export the file in .raw format, so they can be loaded in Axoloti.

Then load the wavefile into a table and then you can use those waveforms for all 3 oscillator banks that you want in your patch. You will save alot of memory this way, cause you dont have to have 3 X saw, square, sine triangle oscillators loaded(12 oscs loaded at all times is a lot), you have just one single table, with the 4 waveforms in and then the 3 oscillator banks share the same waveforms.

To load the wavetable that you create in Audacity, you can do something like this:

Screen Shot 2019-12-16 at 16.56.37.png836x664 47.3 KB

The patch:
Waveforms 1.0 .axp (4.0 KB)

That is the basic playback setup. You want to add envelope, filter and so on. If you need it of course.

So you basically only need to get that wavetable with the waveforms created in Audacity. But yeah if you haven't tried that before, it might be a bit of work.

#3

Hi. Yes that is one approach but when I say different oscillator types, i mean one type could be an fm oscillator core, another would be an wave table, and another a subtractive synth oscillator... for example.

Since I don't want all of them to be loaded at the same time, I would like to be able to load the subpatches dynamically.

I mostly see people using controllers to load different projects altogether... I want my synth to just have one biasic architecture, but radically different signal sources and oscillator techniques...

do you think this would not be feasible with controller objects?

thanks!

#4

Ahh yes, I see that is a different setup overall.

As far as I know, you cannot load subpatches dynamically. The code for each oscillator would have to be loaded into the ram at start up, so it will use the memory that each osc takes, even if the oscillators are not "active".

So no, I don't think it is feasible.

For the setup you are talking about I think I would still use tables for the waveforms as it would use a lot less SRAM, which we don't have a lot of. There are tables that uses SDRAM, which we have a lot more of, so load the waveforms into SDRAM tables, as the one in the patch I posted above and then you would still have more memory to do the fm/additive stuff you mentioned. You can do additive/fm on the table too :slight_smile:

#5

Here is a link to the 4 waveforms, saw, sine, triangle and square, made ready for Axoloti, if you want to try. 4 waves of 2048 samples each = 8192 samples in all. The patch above has the right settings to get it working.

Use the raw file. You need to change the name of the file, as Axoloti doesn't accept spaces in names.

#6

So it would be equivalent to having tons of voices in a polyphonic patch? Damn...

ok back to the drawing board i guess...

#7

Yes if you load 4 oscillators for 3 banks, you would have 12 osc's loaded at all times.

If you want to do other stuff too, I would save all that memory form the 12 osc's by using tables instead.

Maybe other users in here has other suggestions. This is the best I can come up with atm.

#8

If you are not 100% sure what to do, just try to build something that you think will work, even though it uses a lot of ram and cpu. And then you can always optimise it as you learn more :slight_smile:

#9

BTW there are "multiwave oscillators" in the community library, that offers the 4 basic waveforms in a single object They are probably cheaper than loading 4 separate objects. Check @SirSickSik's oscillator folder, for example sss/osc/blepped2.

#10

Hi again...

I was thinking: maybe a work around would just be to make a bunch of copies of my synth, but each with a different set of oscillators types, and then use the controller object to switch between them. It wouldn't be as convenient, but i guess it would get to similar functionality as what i was thinking.

What do you think?

#11

Yeah that could probably work. Make the set ups you want and then use a controller object to change between the patches, with the different setups. Yeah that would work :slight_smile:

#12

I've got quite a large set of oscillators, each having their own way of providing you with different waveforms.
The "blep" oscillators are based on the factory oscillators, but they use a seperate module to contain the functions for these. The second "blep" version also has some extra oscillator functions that I made up myself.
So you can load a couple of these oscillators and choose which waveform you want to use for each seperately.

But I also have a lot of oscillators that build up their waveform in a different way.
Some are wavetable based (several types of modules to build your own set of wavetables, generated in different ways), able to morph through these tables in 1D, 2D or 3D or as a wavetrain.
Others are build around different types of synthesis.
-complex oscs (like the blep osc, but multiple mixable waveform types)
-fm type for bell-type sounds
-ringmod
-synced for nasty basses
-self-modulation (eg classic osc), allowing to morph the sine into other waveforms
-harmonic morphing oscillators (very nice as modulation source)
-some are a combination of two or more of these

#13

Thanks! I will totally check them out. This is my first axo project and I'm almost finished the architecture for it. I now plan on trying out this basic architecture with various kinds of signal sources so I'll definitely try these in there.

How are they efficiency-wise?

#14

totally depends on what you look for. I always try to minimise cpu usage, but some things just take up cpu to do.
Some are designed to just do crazy things that would normally take quite a set of modules to do (or are impossible to do with modules due to the audio-buffer->calculating 16 samples a time for each module and then passing on the audio to the next module, making it impossible to have a direct feedback). Those are best used as monophonic audio effects.
But there are also some that have quite a low cpu use with very basic modulations. My blep oscillators probably use a bit more then the factory ones, but in my case you can load 4 oscillators that each can choose any of the waveforms, without the need of loading 16 of the factory modules into your patch to be able to do that.

If it's the case you still have memory left, but no cpu, you can "silence" the code by adding a mute/on-pin (eg. inlet_on) and add to the code:
outlet_out=0;
if(inlet_on>0){
....your oscillator code...
outlet_out= "the output of your oscillator code"
}

when the "on" pin is low, the oscillator code won't be played, saving you cpu use.