How to use modulation sources

#1

In an effort to understand how modulation sources work, i made this patch....
modulation sources 2.axp (9.6 KB)

modulation sources 2.axp.png1196x516 40.6 KB

#2

fixed in upcoming release

#3

I have a question on mod sources. I didn't know these objects existed (always wondered about the modsource context menu). In my synth patch I have 2 LFO's, 1 Env and 1 Rand sections hard wired into OSC, Filter, VCA etc. Is it more efficient to change this to use modsources or are they fine hardwired?

#4

hmm, interesting question...
looking at the code, Id say there will not be a huge difference in either.... probably slightly more efficient hardwired it just using the outlet for one parameter, and slightly more efficient using mod sources, if you are targeting lots of parameters.
(essentially, both mechanism just write a value somewhere to be evaluated later, and the cost of the table lookup, id suspect is going to optimised out by the compiler)

I guess best way is too try, but I don't think there is much to be gained either way.

@johannes what do you think?

personally... I don't like modulation sources, they make patches very difficult to read, on the main patcher you cannot see easily what they are targeting, this also makes execution order very difficult to read (since its based on where the mod source is vs the parameter is affecting)

however, modulation has two big advantages.
- all parameters can be modulated, and we don't always have inlets for all parameters
- real time attenuation. [ EDIT: oops, wrong my mistake you cant do this, attenuation editing is limited to 'compile time']

In the future we are hoping to enhance axoloti so that all parameters are presented as an inlets, so I think this will reduce mod sources appeal.. however, I think this is very much a personal preference, I can imagine others really find mod sources very appealing/useful... and have a symmetry with the way midi CC mapping works. (but then again , i tend to use midi/in/cc for similar reasons :smile: )

(note: hmm, we could possibly add a UI feature such that highlighting hovering on a mod source, could 'flash' ,or some other metaphor, associated parameters)

#5

also that the output is clipt? didnt make any diffrence with 1.0.7

if modsources would be scaleable eg.from -23 to + 32 .that would be great

#6

from 1.0.7

Screen Shot 2016-02-13 at 16.26.43.png814x539 28.9 KB

now works with 2 mod targets... you need to attenuate to +/- 64.... I guess the +/-127 is to allow some gain on the original signal.

actually, one thing surprised me... as i said, I dont really use them... is I thought you could change the attenuation whilst live, but you cant... so that knocks back one of the uses I thought they had :wink:

(@philoop you used a custom object, so I couldn't test your patch... I only try self contained patches, I know lazy, but I like an easy life )

#7

Parameters are not supposed to be able to go outside their "mechanical" range, so yes, the result of parameter modulation is clipped, and it is intended to be like that.

The intention is to make modulations live adjustable, but it's not there yet.

Parameters as inlets is certainly on the agenda.

But the key benefit of parameters, modulations and presets versus wires is that they are event-driven. That means they cause zero load when they're not updated.
While connections are always updated at control rate.

Using modulations - and then forcing them to update at (near) control rate is not going to bring performance benefits.

#8

I dont use The mod sources much either. You can't set Them while Being live. And you can't use them in presets.

But for parameters With No inlets they are useful 👍 I see that it is mentioned that mod sources can be used for all parameters. That is not entirely true. You cannot use it for ctrl/i for example. This is one of the objects I use the most and have been trying to make it work with midi, in manyyyyyyy different ways but with no luck just yet. And just tested if mod sources worked with it but it doesnt. Still no way to modulate ctrl/i with midi or any other sources besides presets.

A ctrl/i that is midi cc assignable is really, really, high on my wishlist of Axoloti features. Probably highest. Gonna put in wishlist of objects.

#9

ok, I understand they require a trigger to set the value...
but does that mean they are really 'event driven'?

from my understanding this means they simply don't update the table except on trigger...
but the modulated parameter will still be reading the table on each execution cycle.

so there is load... the load in mod source checking the trigger, and the mod target reading the table.

in this manner its similar to a latch... when the latch is storing it its internal value, rather than the table.

(ok, there might be one extra memory location... the outlet of the latch, but who knows how this all gets optimised by the compiler, once the function calls are unrolled.)

am i missing understanding something?

I think really, its impossible for to have anything 'event driven' currently, as its all done on a static call map with values being data being read every cycle (by design, to achieve consistant performance)...
(ok this is true at the patch level only, objects internally of course have conditional paths, usually only externally present by things like rising triggers)

I only mention this, to clarify my understanding... and also I think its an interesting area of possible optimisation in the future.... what I'm thinking is usually the 'load' is not on the source end of the wire, its on the target end... i.e. if you know an inlet/modsource has not changed, then you could prevent certain calculations happening.

anyway, mainly this is 'shooting the breeze' :smile:

#10

modsource_cc and keyb_mod are event driven by incoming midi for example

Reading the parameter table yes, just like a non-modulated parameter, this is unavoidable.
It's not evaluating the modulation sources.

So far modulations target fractional things. Hard to express "modulation amount" when mapping to integers.
I believe I have explained you already why ctrl/i does not have midi mapping. Use "midi/in/cc i" or "ctrl/i radio...".

#11

but evaluating the mod source is not much, its simply copying the value to the table...
providing the value to the inlet is where most of the work is done...
e.g. imagine an LFO connected to a mod source , the lfo is still being evaluate at k-rate, and this is where the load is and passed to the inlet of the mod source, regardless of the modsource/trigger... the trigger simply copies the last value to the table.
(in this way similar to a latch, the upstream process is not prevent, it simple does copy the new value to the outlet)

similarly for mod source_cc , sure, it only copies the values when the midi arrives, but that is also true of the midi/in/cc ... the processing is in the midi handler in both scenarios, and sure that part is event driven. (a function of midi processing not mod sources)

#12

Ahh yes sorry. I didnt try the mod source before and after reading this earlier today, I thought that I might had missed something. And then tried the mod sources with no luck.

Anyway, my main purpose is not really to use it with external midi. I just want to be able to control it internally with lfos or whatever, see the numbers change in realtime. And for that midi cc made most sense. Any other way to approach this is most welcome. ANd the fractional thing you mention is not an issue. I tried with ctrl/radio; assigning it to midi cc and using an lfo to control it. It works perfectly and the ctrl/i would work the same way I am sure. No fractional or integer issues. So I am not sure what you mean.

Using the midi/in/cc i or the ctrl/i radio doesnt do the trick, sorry, but thank you for the suggestion. It doesnt modulate the ctrl/i and doesnt really do what I was aiming for. Believe me, I have tried ANY way to avoid using the ctrl/i object, but havent found it. So still stuck a bit.

I did experiment with a ctrl/i object a while ago and turned it into a radio object... with 128 buttons, hehe :wink: It was like TOOO big to fit on the screen :smile: BUT it worked with midi exactly as I thought it would, but the looks of it is no good. Nee the numberbox, not buttons. Have tried in many ways with no luck just yet. But it must be possible to do this, to make a new object that does this without messing up "the semantics". You mentioned in another thread you could implement it in less than 5 minuts. So I know it is possible and not a substancial effort. Anyway, the radio buttons sends out midi... Still looking for a way for the ctrl/i to take its midi preferences from the java preferences that is related to radio/i instead of ctrl/i. I dont believe it is impossible neither hard to do. So I guess I am going to try again sometime.

I dont see what that problem might be? If it is a problem with the ctrl/i it is also a problem with the radio objects that is cc assignable. They also use integers. And it is not a problem with them. They behave exactly as intendent and as I was hoping. So I dont get what you mean in relation to this. I know ctrl/i goes beyond 0-127, but I am still voting for an "ekstra version" of this object that is midi compliant 0-127. Not a huge efffort :wink:

#13

I think the issue is...
modulation sources are bounded -64/-63, but for a moment consider this instead as -1 to 1,
then are then multiplied by the modulation amount... which is, -127 to 127 , but consider this as -2 to 2.

this means the results is bounded to -2 to 2... which can be easily mapped to fractional parameter

BUT this cannot be done with a int, the multiplier doesn't make any sense, and the output cannot be bound either...
so its very different from what we have now.

dont get me wrong, i do agree to some extent the integer UI is perhaps not served well, e.g. scaling and ranging would be nice. but this is partly for similar reasons, its not bounded.

think of a eurorack system for a moment... it works because things are done within a voltage range.... they are not allowed to just be any voltage e.g 0 to 3123v :smile:

#14

I am not sure I regard it as a problem, But as I mentioned, I did a test with an lfo controlling an radio object(the 128 version I mentioned) and it worked exactly as expected. Just took up too much screen space and no numbers to look at. Ti me scaling is not an issue, this can be done in numerous ways after the integer goes out of the radio or the ctrl/i object.

The scaling I am not worried about at all as mentioned. THere are other scaling in Axoloti that is not "perfect" but it works.... ALso I know how to set minimum and maximum values of the objects on my own and multiplyind/dividing, etc. to get right values. Just looking for help implementing the cc :wink:

But I kind of figured you guys are still thinking about this... But it had been a few months since i mentioned it, so I thought I'd bring it up again and see if any progress had been made or thoughts had been put into it.

Thanks :wink:

#15

Again @jaffasplaffa the 5 minutes addition of midi mapping in ctrl/i causes concerns here that it would conflict/overlap with other future efforts : there is a more general demand for midi mapping parameters to a partial range of the parameter. And that aligns more or less with the requirements for mapping midi to general integers.
First priority is polishing 1.0.7 into a stable release.
Can we now please stick to the topic of modulation sources?

An LFO with pitch parameter but without pitch inlet can outsource the phase increment computation (interpolated table lookup) to a pfunction (where it will only be recomputed when the parameter is actually updated). Such an LFO without pitch inlet would reduce the computational load to almost half in the case of a sine LFO, and even more for square and saw LFO's, still leaving flexibility to modulate the LFO speed with key velocity and a key tracking ratio.

#16

Cool :smile: I am glad it will be brought up later. And I know you said that before, so I just wanted to check if you had put more thoughts into it. I wait a bit longer :wink:

#17

ah, thats the bit I'm missing, whilst Ive seen the pfunc Im still pretty hazy on their uses... I need to dig into them some time when Ive got a clear head - thanks for the explanation/insights.
(can you suggest an object to look at ... that has this pfunc optimisation?)

#18

It's not very clean code, needs refactoring, still I believe it is the way forward.
For example env/d uses a pfunc to convert parameter scale to coefficient required for the dsp function.
Looking at it now, its shift could be eliminated by using SMMLA or SMMLS rather than SMMUL and different coefficients. The effect of removing a single instruction cycle from the dsp workload can be substantial, when it is only a few cycles to begin with.

Streichfett achieves 128 voices polyphony + fx, with an ARM Cortex M4 at less than half the clock speed of Axoloti Core...

#19

thank you all for the discussion.I like to use modsources, they remind of my nord micro modular...nice to hear that they are going to be live editable. I have updated the first post......

#20

Hi!
This patch is just what I was looking for! Thanks for sharing!
May I ask how to you send a value from one object to another object without any cables?
Thanks :slight_smile: