Tinker CV Math Assistant - Now Released (free)

[_andreypetr_]

Currently it's still my favorite reason device and I'm still struggling to get a dynamic LFO shape with all the parameters and curves I need. Maybe Pepin or someone else with experience could help me optimize a bunch of Tinker formulas because ChatGPT cannot do it perfectly yet.

[Loque]

It's something like "Gate1 AND Gate2 = Signal" - guerss you get it... While this is a logical operator, i also had binary operators for logic operands in mind. This could generate interesting results if you blend signals, mask things out and so on... Since i am not a math genious, it is more experimenting....

It's not a substitute for proper comparison and logical operators, but this section of the Tinker manual might be useful to you:
TinkerLogic.png

Not really intuitive IMO...but i will remember this for next time... Hopefully the manual stays forever

[Loque]

Currently it's still my favorite reason device and I'm still struggling to get a dynamic LFO shape with all the parameters and curves I need. Maybe Pepin or someone else with experience could help me optimize a bunch of Tinker formulas because ChatGPT cannot do it perfectly yet.

What do you need? A scalable sine wave? Also here would be more different function sbe interesting...

simplesin.jpg (236.99 KiB) Viewed 3760 times

Here is a simple saw.

simplesaw.jpg (222.41 KiB) Viewed 3756 times

[_andreypetr_]

Currently it's still my favorite reason device and I'm still struggling to get a dynamic LFO shape with all the parameters and curves I need. Maybe Pepin or someone else with experience could help me optimize a bunch of Tinker formulas because ChatGPT cannot do it perfectly yet.

What do you need? A scalable sine wave? Also here would be more different function sbe interesting...
simplesin.jpg


Here is a simple saw.
simplesaw.jpg

You can check out what I've already done. Since Reason doesn't have a dynamic LFO shape generator, I tried to make my own, but I don't like the low maximum steepness of the curve shape and can't find a proper solution for it.

viewtopic.php?f=69&t=7535021&p=676359#p676359

[Pepin]

You can check out what I've already done. Since Reason doesn't have a dynamic LFO shape generator, I tried to make my own, but I don't like the low maximum steepness of the curve shape and can't find a proper solution for it.

viewtopic.php?f=69&t=7535021&p=676359#p676359

I would help, but that's a pretty tricky Combinator to untangle.
Past a certain point, this sort of work becomes "write only"

[_andreypetr_]

You can check out what I've already done. Since Reason doesn't have a dynamic LFO shape generator, I tried to make my own, but I don't like the low maximum steepness of the curve shape and can't find a proper solution for it.

viewtopic.php?f=69&t=7535021&p=676359#p676359

I would help, but that's a pretty tricky Combinator to untangle.
Past a certain point, this sort of work becomes "write only"

For this reason, the original post has a version with a single LFO section, so you can check it out

The idea behind this device is to make it as optimised and simple as possible to be able to have a lot of instances

[selig]

Hey Pepin, I wrote an email to you (which you can now ignore!), but thought I’d ask here as I’m just digging into this fun little RE.
Is there any way to control the rate of the “t” parameter, either from the command line or from external CV?
I wish the lowest rate was 0.001 instead of 0.01, but if I could control the rate (which would be super handy for other stuff too), that would solve this lack of super low frequency control.

[PhillipOrdonez]

Thanks for the free Re! Can’t wait for the video tutorial explaining in simple terms how this works. #NoMathsforMe

[joeyluck]

Happy 2 year anniversary to this RE! It surely doesn't feel like it's been out that long.

[_andreypetr_]

Happy 2 year anniversary to this RE! It surely doesn't feel like it's been out that long.

Surely!!!

[Pepin]

Hey Pepin, I wrote an email to you (which you can now ignore!), but thought I’d ask here as I’m just digging into this fun little RE.
Is there any way to control the rate of the “t” parameter, either from the command line or from external CV?
I wish the lowest rate was 0.001 instead of 0.01, but if I could control the rate (which would be super handy for other stuff too), that would solve this lack of super low frequency control.

I responded to that email before seeing this post, but in case anyone else is interested:

The rate can be automated (via the sequencer menu) or modulated via Combinator. There’s not a dedicated modulation input.

But since ‘t’ is effectively just a sawtooth wave, you can also use the variable inputs to feed a slower sawtooth to Tinker and use that variable instead of ‘t’ in your formula. Shape LFO Editor is one RE I know supports very low rates.

And another option might be automating the knob (‘k’) with a really long clip, depending on your needs—or an external knob as a variable input.

I would help, but that's a pretty tricky Combinator to untangle.
Past a certain point, this sort of work becomes "write only"

For this reason, the original post has a version with a single LFO section, so you can check it out

The idea behind this device is to make it as optimised and simple as possible to be able to have a lot of instances

Gotcha, I’ll take a look later if I get a chance

[motuscott]

It blows my mind what you guys do with Reason sometimes. Not a clue what I’d do with this but congrats on the RE, Pepin. And thanks for offering it for free.

Same.
No idea what this can do, but the fact that Reason exists and folks make tools like this with it blows my mind.
I'm firmly rooted in the twentieth century (electric geetars and acoustic drumbs), but it looks like you kids got this one covered.
Godspeed You Reason Emperors

[_andreypetr_]

Hey Pepin, I wrote an email to you (which you can now ignore!), but thought I’d ask here as I’m just digging into this fun little RE.
Is there any way to control the rate of the “t” parameter, either from the command line or from external CV?
I wish the lowest rate was 0.001 instead of 0.01, but if I could control the rate (which would be super handy for other stuff too), that would solve this lack of super low frequency control.

I responded to that email before seeing this post, but in case anyone else is interested:

The rate can be automated (via the sequencer menu) or modulated via Combinator. There’s not a dedicated modulation input.

But since ‘t’ is effectively just a sawtooth wave, you can also use the variable inputs to feed a slower sawtooth to Tinker and use that variable instead of ‘t’ in your formula. Shape LFO Editor is one RE I know supports very low rates.

And another option might be automating the knob (‘k’) with a really long clip, depending on your needs—or an external knob as a variable input.

For this reason, the original post has a version with a single LFO section, so you can check it out

The idea behind this device is to make it as optimised and simple as possible to be able to have a lot of instances

Gotcha, I’ll take a look later if I get a chance

I think I found it
select(pow(t/max(A,.00001),50),t/(((1/max(1-B,.00001)-2)*(A-t))+A),1-(t-A)/(((1/max(C,.00001)-2)*(1-t))+(1-A)))

And now I found out that RS got rid of 100 symbols restriction per label! I hope this is not a bug.

Okay, so the only thing that Tinker is missing for me now is a latch or a freeze function.

[Pepin]

And now I found out that RS got rid of 100 symbols restriction per label! I hope this is not a bug.

Let me know if you have steps to reproduce this. I've not experienced any change to the limit.

Okay, so the only thing that Tinker is missing for me now is a latch or a freeze function.

Please don't get your hopes up for a feature update
There are existing REs for latching that should work.

[_andreypetr_]

And now I found out that RS got rid of 100 symbols restriction per label! I hope this is not a bug.

Let me know if you have steps to reproduce this. I've not experienced any change to the limit.

Okay, so the only thing that Tinker is missing for me now is a latch or a freeze function.

Please don't get your hopes up for a feature update
There are existing REs for latching that should work.

Yes, it is an interesting bug or something I don't understand. Let's move conversation to PM

[selig]

I responded to that email before seeing this post, but in case anyone else is interested:

The rate can be automated (via the sequencer menu) or modulated via Combinator. There’s not a dedicated modulation input.

But since ‘t’ is effectively just a sawtooth wave, you can also use the variable inputs to feed a slower sawtooth to Tinker and use that variable instead of ‘t’ in your formula. Shape LFO Editor is one RE I know supports very low rates.

And another option might be automating the knob (‘k’) with a really long clip, depending on your needs—or an external knob as a variable input.

Sorry if I wasn't clear, if I want a slow LFO I could use another RE, but I wanted to build one using Tinker. I don't want it tied to automation, looking for a way to build a super slow LFO and Tinker is THIS close to allowing it!
I know you've said no further development on this, but IF you ever go down that road please consider a " super low mode" option for this function. It seems exactly like the type of RE that should allow extremes and few limits since it's just math...

[Loque]

I responded to that email before seeing this post, but in case anyone else is interested:

The rate can be automated (via the sequencer menu) or modulated via Combinator. There’s not a dedicated modulation input.

But since ‘t’ is effectively just a sawtooth wave, you can also use the variable inputs to feed a slower sawtooth to Tinker and use that variable instead of ‘t’ in your formula. Shape LFO Editor is one RE I know supports very low rates.

And another option might be automating the knob (‘k’) with a really long clip, depending on your needs—or an external knob as a variable input.

Sorry if I wasn't clear, if I want a slow LFO I could use another RE, but I wanted to build one using Tinker. I don't want it tied to automation, looking for a way to build a super slow LFO and Tinker is THIS close to allowing it!
I know you've said no further development on this, but IF you ever go down that road please consider a " super low mode" option for this function. It seems exactly like the type of RE that should allow extremes and few limits since it's just math...

Or a continuous sample counter?

I hope, he will give Tinker some more love in future, add a few functions, audio, more macros and more... Fingers crossed

[selig]

Coming from Reaktor, there are things I’ve wanted in Reason for years such as selectors/panners. Tinker does the selectors, even with linear interpolation (exponential would be a nice option), but since there is only one output you can’t do the opposite (panner) which is super helpful when building routing based stuff. I built an 8 way panner in Thor but it’s so clunky to use!

So IF you ever decide to update this, I’d be happy to help and have plenty of suggestions…just saying!

[Loque]

Coming from Reaktor, there are things I’ve wanted in Reason for years such as selectors/panners. Tinker does the selectors, even with linear interpolation (exponential would be a nice option), but since there is only one output you can’t do the opposite (panner) which is super helpful when building routing based stuff. I built an 8 way panner in Thor but it’s so clunky to use!

So IF you ever decide to update this, I’d be happy to help and have plenty of suggestions…just saying!

Good idea
The syntax could be pretty easy like "CVO1=..." Or use X, Y, Z

[Pepin]

I responded to that email before seeing this post, but in case anyone else is interested:

The rate can be automated (via the sequencer menu) or modulated via Combinator. There’s not a dedicated modulation input.

But since ‘t’ is effectively just a sawtooth wave, you can also use the variable inputs to feed a slower sawtooth to Tinker and use that variable instead of ‘t’ in your formula. Shape LFO Editor is one RE I know supports very low rates.

And another option might be automating the knob (‘k’) with a really long clip, depending on your needs—or an external knob as a variable input.

Sorry if I wasn't clear, if I want a slow LFO I could use another RE, but I wanted to build one using Tinker. I don't want it tied to automation, looking for a way to build a super slow LFO and Tinker is THIS close to allowing it!
I know you've said no further development on this, but IF you ever go down that road please consider a " super low mode" option for this function. It seems exactly like the type of RE that should allow extremes and few limits since it's just math...

I'll keep that in mind if I revisit it. I don't really see a huge difference between using 't' vs using 'A' with an external sawtooth personally apart from "portability". That's the main reason 't' was added (so simple generative patches could be saved without a Combinator). Whether using 't' or 'A', the formula for your custom LFO would be identical apart from the variable name. But I can see why it would be nice in certain situations.

In general, Tinker was originally intended to serve as "glue" between other CV devices. There are lots of situations where you want to perform a specific mathematical operation but no device supports it directly, so you're forced to perform obscure Thor maneuvers and the like. It was not intended as a full on "scripting language" for Reason, because the SDK is too limited to support such a thing (in both the UI and performance sense). That's where I'm coming from with the chosen feature set.

[Pepin]

Coming from Reaktor, there are things I’ve wanted in Reason for years such as selectors/panners. Tinker does the selectors, even with linear interpolation (exponential would be a nice option), but since there is only one output you can’t do the opposite (panner) which is super helpful when building routing based stuff. I built an 8 way panner in Thor but it’s so clunky to use!

So IF you ever decide to update this, I’d be happy to help and have plenty of suggestions…just saying!

Good idea
The syntax could be pretty easy like "CVO1=..." Or use X, Y, Z

I'll keep all of these suggestions in mind if I revisit it in the future (not happening soon, to be clear).

I did have a general concept in mind for a more elaborate device (effectively several Tinkers within the same device, with some type of configurable internal routing).

But it's not something I'm pursuing at the moment. Performance is always a consideration with this stuff too. A Tinker formula obviously won't perform as well as compiled C++. And past a certain point of complexity, a user is probably better off learning the latter (i.e. the RE SDK).

Since this is a free RE, its development is ultimately guided by my own needs and what I find interesting during development. I hope that's understandable.

[Loque]

Good idea
The syntax could be pretty easy like "CVO1=..." Or use X, Y, Z

I'll keep all of these suggestions in mind if I revisit it in the future (not happening soon, to be clear).

I did have a general concept in mind for a more elaborate device (effectively several Tinkers within the same device, with some type of configurable internal routing).

But it's not something I'm pursuing at the moment. Performance is always a consideration with this stuff too. A Tinker formula obviously won't perform as well as compiled C++. And past a certain point of complexity, a user is probably better off learning the latter (i.e. the RE SDK).

Since this is a free RE, its development is ultimately guided by my own needs and what I find interesting during development. I hope that's understandable.

Yes, sure, no problem.

I also just like the discussion what's possible. Regarding performance I am curious about the code. I guess the AST is generated when the text is changed.. more performance optimisations could be to reduce the amount of steps to execute it. In the end it is e list of executable steps. Not much room for optimisations at this point, depending on how the steps are executed... Small optimisations could be to replace division by bit shifts, Integer or fixed floats instead of real, table look up instead of calculations...

[Pepin]

I'll keep all of these suggestions in mind if I revisit it in the future (not happening soon, to be clear).

I did have a general concept in mind for a more elaborate device (effectively several Tinkers within the same device, with some type of configurable internal routing).

But it's not something I'm pursuing at the moment. Performance is always a consideration with this stuff too. A Tinker formula obviously won't perform as well as compiled C++. And past a certain point of complexity, a user is probably better off learning the latter (i.e. the RE SDK).

Since this is a free RE, its development is ultimately guided by my own needs and what I find interesting during development. I hope that's understandable.

Yes, sure, no problem.

I also just like the discussion what's possible. Regarding performance I am curious about the code. I guess the AST is generated when the text is changed.. more performance optimisations could be to reduce the amount of steps to execute it. In the end it is e list of executable steps. Not much room for optimisations at this point, depending on how the steps are executed... Small optimisations could be to replace division by bit shifts, Integer or fixed floats instead of real, table look up instead of calculations...

Yeah, that's basically how it works. The lexer and parser ultimately construct a syntax tree whenever the formula changes. The parser uses precedence climbing if you're curious. The lexing and parsing are done from JBox_Export_CreateNativeObject, while the syntax tree is evaluated in JBox_Export_RenderRealtime. The latter is the performance critical part.

[selig]

Sorry if I wasn't clear, if I want a slow LFO I could use another RE, but I wanted to build one using Tinker. I don't want it tied to automation, looking for a way to build a super slow LFO and Tinker is THIS close to allowing it!
I know you've said no further development on this, but IF you ever go down that road please consider a " super low mode" option for this function. It seems exactly like the type of RE that should allow extremes and few limits since it's just math...

I'll keep that in mind if I revisit it. I don't really see a huge difference between using 't' vs using 'A' with an external sawtooth personally apart from "portability". That's the main reason 't' was added (so simple generative patches could be saved without a Combinator). Whether using 't' or 'A', the formula for your custom LFO would be identical apart from the variable name. But I can see why it would be nice in certain situations.

In general, Tinker was originally intended to serve as "glue" between other CV devices. There are lots of situations where you want to perform a specific mathematical operation but no device supports it directly, so you're forced to perform obscure Thor maneuvers and the like. It was not intended as a full on "scripting language" for Reason, because the SDK is too limited to support such a thing (in both the UI and performance sense). That's where I'm coming from with the chosen feature set.

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).

[Pepin]

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