Tinker CV Math Assistant - Now Released (free)

[Pepin]

Given recent discussions, I'm going to be releasing a quick update to Tinker adding a few things:

• Notes names available as constants as well as 'semi' (1/127) and 'oct' (12/127). The one caveat is "negative" octaves will be represented using a tilde ('~') rather than a dash to avoid conflict with the minus sign. Letters will be lowercase to more easily distinguish from input variables. In other words, you can type c4, b~1, c#3 directly as constants.
• remap(x,a,b,c,d): This works like a generalization of the typical bipolar/unipolar conversion. In other words, it remaps a value x from [a, b] to [c, d]. There's no clamping, and "backwards" intervals are allowed.
• spread(x,a,b): This is like the opposite of 'clamp'. Values inside the range are spread to the edges (whichever is closer).
  
  I added those features today. I will also investigate supporting a slower 't' in some form.
  
  There may be some further changes, but I'm keeping this update small as it's all I can do at the moment. There won't be any major UI changes or new syntax.
  I'll post again once a beta is ready.

[_andreypetr_]

Given recent discussions, I'm going to be releasing a quick update to Tinker adding a few things:

• Notes names available as constants as well as 'semi' (1/127) and 'oct' (12/127). The one caveat is "negative" octaves will be represented using a tilde ('~') rather than a dash to avoid conflict with the minus sign. Letters will be lowercase to more easily distinguish from input variables. In other words, you can type c4, b~1, c#3 directly as constants.
• remap(x,a,b,c,d): This works like a generalization of the typical bipolar/unipolar conversion. In other words, it remaps a value x from [a, b] to [c, d]. There's no clamping, and "backwards" intervals are allowed.
• spread(x,a,b): This is like the opposite of 'clamp'. Values inside the range are spread to the edges (whichever is closer).
  
  I added those features today. I will also investigate supporting a slower 't' in some form.
  
  There may be some further changes, but I'm keeping this update small as it's all I can do at the moment. There won't be any major UI changes or new syntax.
  I'll post again once a beta is ready.

What a huge news! Adorable!

[Loque]

...

[electrofux]

Great stuff!

[selig]

I just wanted a slower LFO, not a new feature (but that would be nice too). So ignore the idea of “feature set” for a moment and consider if having slower rates makes sense or not - it would be useful for my work (is all I’m saying with these comments).

I mentioned the feature set stuff more in relation to other proposed features (stuff that requires multiple outputs or more complex syntax). Narrowly speaking, a slower LFO makes sense. The lower bound was a somewhat arbitrary choice to begin with, but it can't be changed without breaking backwards compatibility at this point. I might consider it in the future if there's an elegant way to support it without breaking backwards compatibility or requiring an explicit compatibility switch. No guarantees though, as no updates are planned currently. If that changes, you'll be the first to know

If you were able to provide a way to modulate rate, internally with a variable and externally via CV, that’s all that is needed I would think. This would allow you to simply multiply rate by 0,5 for half the rate etc.
This would also avoid breaking backwards compatibility as well as adding the ability to create more complex formulas/shapes that are interactive - win/win IMO!
Thanks for taking the time to look into this, you’re making a cool little device even cooler!

[Loque]

I mentioned the feature set stuff more in relation to other proposed features (stuff that requires multiple outputs or more complex syntax). Narrowly speaking, a slower LFO makes sense. The lower bound was a somewhat arbitrary choice to begin with, but it can't be changed without breaking backwards compatibility at this point. I might consider it in the future if there's an elegant way to support it without breaking backwards compatibility or requiring an explicit compatibility switch. No guarantees though, as no updates are planned currently. If that changes, you'll be the first to know

If you were able to provide a way to modulate rate, internally with a variable and externally via CV, that’s all that is needed I would think. This would allow you to simply multiply rate by 0,5 for half the rate etc.
This would also avoid breaking backwards compatibility as well as adding the ability to create more complex formulas/shapes that are interactive - win/win IMO!
Thanks for taking the time to look into this, you’re making a cool little device even cooler!

I suggested sample ticks for this, but another solution could be song position. The problem with a rate is, that it is repetitive and depends on cycles, which break when changed.

[selig]

If you were able to provide a way to modulate rate, internally with a variable and externally via CV, that’s all that is needed I would think. This would allow you to simply multiply rate by 0,5 for half the rate etc.
This would also avoid breaking backwards compatibility as well as adding the ability to create more complex formulas/shapes that are interactive - win/win IMO!
Thanks for taking the time to look into this, you’re making a cool little device even cooler!

I suggested sample ticks for this, but another solution could be song position. The problem with a rate is, that it is repetitive and depends on cycles, which break when changed.

I’m not following - neither of those would do what I’m suggesting/wanting if I’m understanding you correctly.
Clarification:
As it is today, if you change tempo, the rate of “t” changes. So rate can obviously change already, and do so at any time and dynamically with any tempo changes.
My suggestion is not adding a new underlying feature, it’s just allowing the user to access an existing feature via a different approach (CV controlling Rate instead of song tempo, in this example). Am I making sense?

[Loque]

I suggested sample ticks for this, but another solution could be song position. The problem with a rate is, that it is repetitive and depends on cycles, which break when changed.

I’m not following - neither of those would do what I’m suggesting/wanting if I’m understanding you correctly.
Clarification:
As it is today, if you change tempo, the rate of “t” changes. So rate can obviously change already, and do so at any time and dynamically with any tempo changes.
My suggestion is not adding a new underlying feature, it’s just allowing the user to access an existing feature via a different approach (CV controlling Rate instead of song tempo, in this example). Am I making sense?

You are right. I understand you want it related to the tempo. So it must be something that is counting based on tempo without a closed cycle. Right?

[selig]

I’m not following - neither of those would do what I’m suggesting/wanting if I’m understanding you correctly.
Clarification:
As it is today, if you change tempo, the rate of “t” changes. So rate can obviously change already, and do so at any time and dynamically with any tempo changes.
My suggestion is not adding a new underlying feature, it’s just allowing the user to access an existing feature via a different approach (CV controlling Rate instead of song tempo, in this example). Am I making sense?

You are right. I understand you want it related to the tempo. So it must be something that is counting based on tempo without a closed cycle. Right?

No, not exactly. I’m saying it already IS related to tempo. Meaning, Rate is already controlled externally, I just want access to that control point from a user perspective instead of tempo being the ONLY means to control rate externally.

Think of Pulsar - you can control the Rate of LFO 1 from LFO 2, or from external CV, and of course from Tempo. Tinker can currently do the Tempo bit, but not the CV or internal control bit.

This solution is a “2 for 1” solution, as you not only have a way to drive rate lower than the front panel control but also to modulate rate from another Tinker as one example.

The other key takeaway is that this approach is backwards compatible, unlike extending the current range. And it’s also flexible since there would be no internal ‘clamping’ of values at the front panel settings (translation: CV can drive the rate beyond the panel controls). Thus, no restrictions on how fast or slow it can go, from DC to Nyquist! Plus, allowing DC means you can “freeze” the LFO function at any point which is a handy function IMO.

All to say, I’d rather have this solution (user control over Rate) rather than something like adding a “slow” mode (which still leaves arbitrary restrictions on rate). Plus this solution is 100% backwards compatible and doesn’t require any UI changes at all. It also allows things like a 2x or 4x button for musical/rhythmic changes, or whatever change you want.

[Pepin]

Clarification:
As it is today, if you change tempo, the rate of “t” changes. So rate can obviously change already, and do so at any time and dynamically with any tempo changes.
My suggestion is not adding a new underlying feature, it’s just allowing the user to access an existing feature via a different approach (CV controlling Rate instead of song tempo, in this example). Am I making sense?

Non-synced rate of ‘t’ doesn’t change with tempo unless you are automating the rate. But I guess that’s what you’re doing? Modulation is possible via the combinator but will be clamped to configurable range.

To clarify, those things (automation and combinator modulation) are what we get “for free”. The RE sees those as no different from the user manually changing the panel. Modulation via CV or some internal source is not the same thing code-wise. It can be done, but it is a new feature.

Currently what I was imagining is simply a third mode for the rate that’s measured in seconds rather than Hz. To me, that seems like a better way to configure a long LFO than scaling tiny Hz values.

[Pepin]

Edit: Ignore. Had a mistake in there about how the free rate works on Tinker.

[Pepin]

If you were able to provide a way to modulate rate, internally with a variable and externally via CV, that’s all that is needed I would think. This would allow you to simply multiply rate by 0,5 for half the rate etc.
This would also avoid breaking backwards compatibility as well as adding the ability to create more complex formulas/shapes that are interactive - win/win IMO!
Thanks for taking the time to look into this, you’re making a cool little device even cooler!

Reading this thread more thoroughly, I'm getting rather confused.

To clarify, what would modulating the rate with a bipolar sine wave do?
Typically, one would expect it to modulate the rate above and below its current setting, usually with some clamping applied.
But your example behaves differently since 0.5 halves the rate. That's just a direct multiplication. I don't think that's how most users would expect modulation to behave. I guess you're imagining more of a "scale" setting?

All to say, I’d rather have this solution (user control over Rate) rather than something like adding a “slow” mode (which still leaves arbitrary restrictions on rate). Plus this solution is 100% backwards compatible and doesn’t require any UI changes at all. It also allows things like a 2x or 4x button for musical/rhythmic changes, or whatever change you want.

For the record, a 2x or 4x button is already possible today, but a 1/2x button is not.
I'm not sure how you'd imagine a 1/2x button being built using the change you propose though.
If you're going with "scale" style modulation, then mapping the button to the rate will just make it zero when off. I guess you'd need a "scale" style modulation that still somehow has an "amount" setting? Something like a crossfade between the original and multiplied settings?

Not sure how I feel about this whole idea. That compatibility switch is starting to sound quite nice right about now

[_andreypetr_]

I mentioned the feature set stuff more in relation to other proposed features (stuff that requires multiple outputs or more complex syntax). Narrowly speaking, a slower LFO makes sense. The lower bound was a somewhat arbitrary choice to begin with, but it can't be changed without breaking backwards compatibility at this point. I might consider it in the future if there's an elegant way to support it without breaking backwards compatibility or requiring an explicit compatibility switch. No guarantees though, as no updates are planned currently. If that changes, you'll be the first to know

If you were able to provide a way to modulate rate, internally with a variable and externally via CV, that’s all that is needed I would think. This would allow you to simply multiply rate by 0,5 for half the rate etc.
This would also avoid breaking backwards compatibility as well as adding the ability to create more complex formulas/shapes that are interactive - win/win IMO!
Thanks for taking the time to look into this, you’re making a cool little device even cooler!

You can already control rate with a variable with the formula:
(round(1+select(1-K,1,1/2,1/3,1/4,1/6,1/8,1/12,1/16,1/24,0)*10)*t)%1

[selig]

If you were able to provide a way to modulate rate, internally with a variable and externally via CV, that’s all that is needed I would think. This would allow you to simply multiply rate by 0,5 for half the rate etc.
This would also avoid breaking backwards compatibility as well as adding the ability to create more complex formulas/shapes that are interactive - win/win IMO!
Thanks for taking the time to look into this, you’re making a cool little device even cooler!

Reading this thread more thoroughly, I'm getting rather confused.

To clarify, what would modulating the rate with a bipolar sine wave do?
Typically, one would expect it to modulate the rate above and below its current setting, usually with some clamping applied.
But your example behaves differently since 0.5 halves the rate. That's just a direct multiplication. I don't think that's how most users would expect modulation to behave. I guess you're imagining more of a "scale" setting?

All to say, I’d rather have this solution (user control over Rate) rather than something like adding a “slow” mode (which still leaves arbitrary restrictions on rate). Plus this solution is 100% backwards compatible and doesn’t require any UI changes at all. It also allows things like a 2x or 4x button for musical/rhythmic changes, or whatever change you want.

For the record, a 2x or 4x button is already possible today, but a 1/2x button is not.
I'm not sure how you'd imagine a 1/2x button being built using the change you propose though.
If you're going with "scale" style modulation, then mapping the button to the rate will just make it zero when off. I guess you'd need a "scale" style modulation that still somehow has an "amount" setting? Something like a crossfade between the original and multiplied settings?

Not sure how I feel about this whole idea. That compatibility switch is starting to sound quite nice right about now

The idea was SIMPLE. The conversation between Loque and myself was not. Ignore everything we said!
If you cannot divide in half as you explained, then my simple solution of using MATH (because it’s in the name) makes more sense, no? It IS a new feature, btw, I’m well aware I’m asking for a new feature and well aware you may not see fit to implement it for free! I’m giving you a few ways to make it happen, maybe that’s the confusion.

Again think of Pulsar, which has an LFO that can be rate modulated internally OR externally and who’s rate is not clamped internally. But Pulsar stalls when you drive it too slow, so I’ve stopped using it for this.

Sorry for any confusion, I want slower than 0.01Hz and know you can’t just change the range, so I suggested multiplier buttons first, THEN suggested CV modulation of the rate to do the same trick we do in Thor or Pulsar to get ranges outside the knob value. Nothing more, sorry about the confusion!

[selig]

If you were able to provide a way to modulate rate, internally with a variable and externally via CV, that’s all that is needed I would think. This would allow you to simply multiply rate by 0,5 for half the rate etc.
This would also avoid breaking backwards compatibility as well as adding the ability to create more complex formulas/shapes that are interactive - win/win IMO!
Thanks for taking the time to look into this, you’re making a cool little device even cooler!

You can already control rate with a variable with the formula:
(round(1+select(1-K,1,1/2,1/3,1/4,1/6,1/8,1/12,1/16,1/24,0)*10)*t)%1

All I need is a way to turn 0.01Hz into 0.001Hz, to get a rate OUTSIDE of the current range. Your formula does not look like it’s doing that or am I missing something?

[electrofux]

Wile you are at it and maybe it can be achieved "just" via an internal option, could the Button of Tinker be optionally switched to momentary mode?

[Pepin]

Wile you are at it and maybe it can be achieved "just" via an internal option, could the Button of Tinker be optionally switched to momentary mode?

I don't think it would be possible to switch between them in the "folded" state.
Edit: To clarify, I mean the folded state would need to always be 'toggle', even if the unfolded one was able to swap between them. This is due to the "visibility_switch" attribute in the SDK only applying to unfolded panels.

[electrofux]

Wile you are at it and maybe it can be achieved "just" via an internal option, could the Button of Tinker be optionally switched to momentary mode?

I don't think it would be possible to switch between them in the "folded" state.
Edit: To clarify, I mean the folded state would need to always be 'toggle', even if the unfolded one was able to swap between them. This is due to the "visibility_switch" attribute in the SDK only applying to unfolded panels.

I think that wouldnt makes sense then as it would introduce weird inconsistencies.

I thought there is a chance that the option could connect where the toggle function is being implemented and switch there to momentary without having to add another button because the difference is not that big. But i guess a toggle button is a predefined building block that has not much to mess around with. And it sounds you need an additional button that and make the other invisible.

Edit: just realized even if the behaviour of the button could be changed on like an object level, the option itself also needs to reset the button to zero in case the button is switched on and you change the option and i can imagine that may not be possible.

[_andreypetr_]

You can already control rate with a variable with the formula:
(round(1+select(1-K,1,1/2,1/3,1/4,1/6,1/8,1/12,1/16,1/24,0)*10)*t)%1

All I need is a way to turn 0.01Hz into 0.001Hz, to get a rate OUTSIDE of the current range. Your formula does not look like it’s doing that or am I missing something?

No, there's no way yet, I just wanted to say that you can use another source instead of t and control it's rate with this formula.

[Pepin]

The upcoming release will have two different 't' variables, t1 and t2 (aliased as 't' and 'T' if you need the extra space).

t1 is the same as the current t.

t2 has its free rate measured in seconds rather than Hz, with an extended range (.01s to 1000s).
I've also added a few faster synced rates for both of them (1/128D, 1/64T, 1/128).

There will also be dedicated CV outs for t1, t2, K, and S.

I'm still exploring a couple additional features. Stay tuned for more details

[Loque]

The upcoming release will have two different 't' variables, t1 and t2 (aliased as 't' and 'T' if you need the extra space).

t1 is the same as the current t.

t2 has its free rate measured in seconds rather than Hz, with an extended range (.01s to 1000s).
I've also added a few faster synced rates for both of them (1/128D, 1/64T, 1/128).

There will also be dedicated CV outs for t1, t2, K, and S.

I'm still exploring a couple additional features. Stay tuned for more details

Does T2 overflow after 1000s? In fact it could overflow at any time throughout the work with Tinker, right?

And nice to see you working on this peace of gold

[Pepin]

The upcoming release will have two different 't' variables, t1 and t2 (aliased as 't' and 'T' if you need the extra space).

t1 is the same as the current t.

t2 has its free rate measured in seconds rather than Hz, with an extended range (.01s to 1000s).
I've also added a few faster synced rates for both of them (1/128D, 1/64T, 1/128).

There will also be dedicated CV outs for t1, t2, K, and S.

I'm still exploring a couple additional features. Stay tuned for more details

Does T2 overflow after 1000s? In fact it could overflow at any time throughout the work with Tinker, right?

And nice to see you working on this peace of gold

What do you mean by “overflow”? The variable is between 0 and 1 just like t1.

[Loque]

Does T2 overflow after 1000s? In fact it could overflow at any time throughout the work with Tinker, right?

And nice to see you working on this peace of gold

What do you mean by “overflow”? The variable is between 0 and 1 just like t1.

That means yes. It will start at 0.01 after 1000s are over. It can happen at any time. It is not bound to something like the song position or it cannot be synced.

Just wanted to understand it, because I was still looking for something which counts endless. I could bound such a value by using module operations and could define the range by myself.