Do you mean that they have to be scaled as a proportion within that range? How would I do that in this case? I'll check that VST out - thanks! I was actually just looking for a VST, so I'm happy to use them if necessary.Loque wrote: ↑23 Apr 2019You need to normalize the CV values between "-1.0<0<+1.0".
I tend to use https://socalabs.com/developer-tools/maths/ if i need something special and math-orientated stuff. Sadly it is a VST and not a RE and you need to convert from CV to Audio first and than back again.
Not sure what you expect with your math, because the result is that number above 1.0. What is the maximum it should reach? if it is 1.0 than just round it (cut it with max(1,yourvalue)), if it need to be scaled, scale it down by dividing.mashers wrote: ↑23 Apr 2019Do you mean that they have to be scaled as a proportion within that range? How would I do that in this case? I'll check that VST out - thanks! I was actually just looking for a VST, so I'm happy to use them if necessary.Loque wrote: ↑23 Apr 2019You need to normalize the CV values between "-1.0<0<+1.0".
I tend to use https://socalabs.com/developer-tools/maths/ if i need something special and math-orientated stuff. Sadly it is a VST and not a RE and you need to convert from CV to Audio first and than back again.
What I would really love is a REwith a programming language built in. Nothing elaborate, just basic if/then/elseif/else, variables and arithmetic operators. That would allow you to do pretty much anything with a CV source and output the result. Sadly I don't think anything like that exists, and although I'm a software developer myself, I don't have time to learn the RE API
I don't think that would work. In my example, I was expecting a result of 4 (16/4). That means a CV value of 0.03125. Putting a ceiling of 1.0 on it would result in an integer value of 127. I think the problem is that when the integer values are converted to CV range, and become less than 1.0, the result becomes exponentially larger when dividing, rather than becoming smaller.
That's a shame. I wonder why it's not allowed? It's not like something with such basic functions could be used as an exploit. Perhaps they're worried about somebody inevitably porting Doom to itLoque wrote: ↑23 Apr 2019There was an attempt for such a RE AFAIK and it is forbidden. Would be very usefull...with a few knobs, buttons, input field, and some connections on the back for audio and CV. And finally the possibility to work on a buffer instead of just a sample. A simple JS engine would be could even if i have JS, but could be quite easy to integrate...
CV always uses the 0.0 to 1.0 range internally, that's how it's delivered via CV jacks. What an instrument or effect does with that range (e.g. map 0.0 to 0, and 1.0 to 127) is up to the device. The note mapping is standardized as 0 to 127, but the rounding is still up to the device to get right (e.g. is a CV value of 0.5, MIDI note 63, or 64?). Other devices don't map it to an integer at all, when controlling knobs, but instead apply decimal values directly as an offset. There's also no limit for the CV range. Generally 0.0 to 1.0 is the working range for unipolar values, and -1.0 to 1.0 is for bipolar. But values outside of that range can easily be sent over CV cables. What happens when interpreted by the device (e.g. clamped to a max of 1.0) is entirely dependent on how the device is coded.mashers wrote: ↑23 Apr 2019I don't think that would work. In my example, I was expecting a result of 4 (16/4). That means a CV value of 0.03125. Putting a ceiling of 1.0 on it would result in an integer value of 127. I think the problem is that when the integer values are converted to CV range, and become less than 1.0, the result becomes exponentially larger when dividing, rather than becoming smaller.
I think that's what I was trying to get across when I said about it being a fraction of 128. It's like defining colours in the Cocoa API; the RGB values are 0-255, but in Cocoa you have to express them as floating point values in the range 0.0..1.0. So if you know the RGB values, you divide them by 255 to get the floating point value. I interpret CV the same: 0.0..1.0 (or -1.0..1.0), as representations of a range from 0-127. I get what you are saying about the device being responsible for the subsequent conversion and interpretation of the value within the normal range (or otherwise) and I suspect I may be falling foul of some of the conversion here.ScuzzyEye wrote: ↑23 Apr 2019CV always uses the 0.0 to 1.0 range internally, that's how it's delivered via CV jacks. What an instrument or effect does with that range (e.g. map 0.0 to 0, and 1.0 to 127) is up to the device. The note mapping is standardized as 0 to 127, but the rounding is still up to the device to get right (e.g. is a CV value of 0.5, MIDI note 63, or 64?). Other devices don't map it to an integer at all, when controlling knobs, but instead apply decimal values directly as an offset. There's also no limit for the CV range. Generally 0.0 to 1.0 is the working range for unipolar values, and -1.0 to 1.0 is for bipolar. But values outside of that range can easily be sent over CV cables. What happens when interpreted by the device (e.g. clamped to a max of 1.0) is entirely dependent on how the device is coded.
So maybe if you approach the math from the perspective that CV is always a decimal, and is only scaled to an integer for display or use inside the device, you may have a better idea of what's going on.
CV values are passed using 64-bit floating point. But it may hit a limit around 3.4E+38, if passes through a 32-bit float anywhere. Also the upper limit for the integer range stored without loss in a 32-bit floats is 16,777,215.
I tried it, and the meter topped out at 8.0 raw value, or 100% signal value, and capped the CV integer value at 127. So I assume that either the VST is preventing it from overflowing, or the CV meter is, or more likely Reason's CV engine.
The problem here is that with the arithmetic RE I tried, you can't input a decimal value. You can only use CV inputs as variables, which means all of your available factors are fractions of 1.0. You can't multiply it by anything > 1. The Maths VST solved this problem because you can actually type in the equation, meaning you can add integer values to correct for this issue.WongoTheSane wrote: ↑23 Apr 2019If you multiply the divisor by 256, you'll get the result you expect.
16 / 4 = 4
0.0625 / ( 0.015625 * 256 ) = 0.015625
Stab in the dark here, but wouldn't it be possible to have a device output a value of 1, then go through a CV Janitor on both inputs in series, each doubling the value, and then use that to have a value of 4 as CV input? I understand it's pretty moot as the value you want as divisor would change over time, but it might be a starting point...mashers wrote: ↑23 Apr 2019
The problem here is that with the arithmetic RE I tried, you can't input a decimal value. You can only use CV inputs as variables, which means all of your available factors are fractions of 1.0. You can't multiply it by anything > 1. The Maths VST solved this problem because you can actually type in the equation, meaning you can add integer values to correct for this issue.
Possibly, but I suspect I would have the same problem sending in a signal which had been doubled and doubled again as I did when I just sent a value of four. If you have a look at my thread about splitting a Combi knob to control four devices, you’ll see that the VST solution actually worked better than I could have hopedWongoTheSane wrote: ↑23 Apr 2019Stab in the dark here, but wouldn't it be possible to have a device output a value of 1, then go through a CV Janitor on both inputs in series, each doubling the value, and then use that to have a value of 4 as CV input? I understand it's pretty moot as the value you want as divisor would change over time, but it might be a starting point...mashers wrote: ↑23 Apr 2019
The problem here is that with the arithmetic RE I tried, you can't input a decimal value. You can only use CV inputs as variables, which means all of your available factors are fractions of 1.0. You can't multiply it by anything > 1. The Maths VST solved this problem because you can actually type in the equation, meaning you can add integer values to correct for this issue.
Yes, a very interesting solution, I'm going to try this too!mashers wrote: ↑23 Apr 2019Possibly, but I suspect I would have the same problem sending in a signal which had been doubled and doubled again as I did when I just sent a value of four. If you have a look at my thread about splitting a Combi knob to control four devices, you’ll see that the VST solution actually worked better than I could have hoped
It certainly opens up some very interesting possibilities for iterative, modulated sequencing and parameter modifications. Anything which is controllable using CV can be modified using an equation which can take other CV sources as a variable...
Users browsing this forum: Google [Bot] and 34 guests
Share and download patches!
Join ReasonTalk on Slack!