DSP Robotics Support

From what I remember the speed knob is connected to a selector, so outputs what ever the current selection is there is no need for correlation between the two. ie the knob could go 1,2,3,4 and output 1bar,7bars,3bars,1/8bar.
Or I could be totally wrong and its used as a divider ie 1 = 1 bar, 2 = 1 bar/2 = 1/2 bar, 4 = 1bar/4 = 1/4 bar.
Not at the right computer right now so cannot check (flowstone's banned from the bedroom ).

Perfect Human Interface wrote:The schematic should adjust to different time signatures. Nubeat's sync modules did take in the time sig values so I assume it is doing so. But the "speed" selector outputs values that are different than I expect. The selector is for the sync rate in "bars," and I'd expect them to be the reciprocal (i.e. 1 bar = 1, 2 bar = 1/2, 1/4 bar = 4)

Actually i like the speed to be shown in bars. 1/4 for 4 bars is a bit confusing, to me.
It seems to work fine with other time signatures too. Except with 3 and 6 bars, they're not accurate, I'll work on that.
Another thing to look into is that speed in free mode should be displayed in Hz.

Perfect Human Interface wrote:I mean you can do both. Sync using your codes while playing and calculate Hz to the OSC prims while not playing.

That's a great idea!

Perfect Human Interface wrote:could you explain why the values used in the selector are 4x what I'd expect them to be (1 bar = 4, etc.)? It's really confusing me.

It just does man! Take it with nubeat7! hehe

Father wrote:Actually i like the speed to be shown in bars. 1/4 for 4 bars is a bit confusing, to me.

It's not though. I mean the decimal values output by the selector, not the actual display strings. The values are the reciprocal of the number of bars multiplied by 4. So 1/8 bar = 32. That's even more confusing.

its because you multiply PPQ with speed, so it counts faster and you get a shorter ramp..

btw you can reduce the code to, maybeit is better to understand like this:


the thing is that this is already an optimized version and i also don't know if my naming is very good,
the original version was to divide (PPQ*Speed)/barcount where barcount is the product of num and denom
but it needs much less cpu to avoid divisions and make a multiplication with the reciprocal value of the divisor, thats why i do a multiplikation with the inverted barcount (1/barcount).. all this math stuff really is not my world and i needed to try out lots of ways to find a working way.. you can watch my bloody beginnings and the way i had to walk till the end here viewtopic.php?f=3&t=1001 thanks to some great people here in the forum which gave me some kicks in the right direction..

Additionally to Nubeat7's description:

Perfect Human Interface wrote:It's not though. I mean the decimal values output by the selector, not the actual display strings. The values are the reciprocal of the number of bars multiplied by 4. So 1/8 bar = 32. That's even more confusing.

You are close to the solution, as you already saw that there is a factor of 4 involved.

It's a speed value, so I'd expect to see a higher value the shorter the range. One cycle of the lfo running through 8 bars is much slower than the same cycle running just through a 1/8 bar. And indeed this is what you see here.

You just need to see the values as relative ones, not absolute. If you do that you also instantly see what the values are related to. The only "1" there is, stands for 4 bars. Now just calculate: how many quarters fit into 4 bars? Yes, 16. And if you look at the value for "1/4" you'll be surprised. It reads 16! Just as expected

You're not quite right. What you're saying would be correct if it was just the reciprocal (as in my LFO). NOT true for the reciprocal * 4. If you multiplied by 4 and then took the reciprocal, it would be beats (but still only true if the time sig is 4 beats per bar). These are not the same thing!

tulamide wrote:The only "1" there is, stands for 4 bars. Now just calculate: how many quarters fit into 4 bars? Yes, 16. And if you look at the value for "1/4" you'll be surprised. It reads 16! Just as expected

That's not "16" for 1 bar, that's "16" for 1/4 bar.

4 bars = 16 beats
reciprocal of 4 = 1/4; 1/4 * 4 = 1

1/4 bar = 1 beat
reciprocal of 1/4 = 4; 4 * 4 = 16

So it's not representing beats. It's not representing anything except the reciprocal * 4.

ok, i'm really confused now too, so please tell me what a bar is

lets say we use 4/4

is a bar 4 quater notes? or 4*4 quater notes?
sadly i'm not a musician as i always understood it a beat is 4 quater notes and a bar is 4 beats (16 quaternotes)

so if we use 3/4
a beat would be 3 quaternotes and a bar would be 12 quaternotes

i'm right with this ?

because when not my calculation would be wrong to multiply num and denom to get barlenght!?

and how is it with 7/8?

Perfect Human Interface wrote:You're not quite right. What you're saying would be correct if it was just the reciprocal (as in my LFO). NOT true for the reciprocal * 4. If you multiplied by 4 and then took the reciprocal, it would be beats (but still only true if the time sig is 4 beats per bar). These are not the same thing!

tulamide wrote:The only "1" there is, stands for 4 bars. Now just calculate: how many quarters fit into 4 bars? Yes, 16. And if you look at the value for "1/4" you'll be surprised. It reads 16! Just as expected

That's not "16" for 1 bar, that's "16" for 1/4 bar.

4 bars = 16 beats
reciprocal of 4 = 1/4; 1/4 * 4 = 1

1/4 bar = 1 beat
reciprocal of 1/4 = 4; 4 * 4 = 16

So it's not representing beats. It's not representing anything except the reciprocal * 4.

You're missing the point. I clearly said that the speed value is a relative value that's referring to 4 bars as 100% (number 1). All other values are then relations to those 4 bars! A 4-bar-package is 1, so a half 8-bar-package fits into one 4-bar-package, ergo 0.5. A half-note-package fits into a 4-bar-package 8 times, ergo value 8. A 1/32-note package fits into a 4-bar-package 128 times, ergo value 128.

Forget about the 1-bar, the base here is 4-bars! You really make it too complicated

Nubeat7 wrote:ok, i'm really confused now too, so please tell me what a bar is

lets say we use 4/4

is a bar 4 quater notes? or 4*4 quater notes?
sadly i'm not a musician as i always understood it a beat is 4 quater notes and a bar is 4 beats (16 quaternotes)

so if we use 3/4
a beat would be 3 quaternotes and a bar would be 12 quaternotes

i'm right with this ?

because when not my calculation would be wrong to multiply num and denom to get barlenght!?

and how is it with 7/8?

There are quite a few names and they all mean something else, depending on the situation. For example, the term "beat" is known in relation to a metronome. It does x many beats per minute. What is meant by that is that it does signalize the beginning of a quarter note per beat. So 120 bpm means 120 quarter notes per minute.

But a quarter note fits into different time signatures. The well known 4/4 time signature means 4x a quarter note. So if you play 4 quarter notes, you've played one bar.

A bar is one cycle of the time signature.

In the time signature 3/4 you only have 3 quarter notes per bar. And in the time signature 6/8 you're playing 6 1/8th notes per bar. While the last example mathematically is the same as 3/4, a musician counts both differently (for 3/4 it's one, two, three, one two three, etc., for 6/8 it's one, two, three, ..., six, one, two, three, ..., six, etc.)

To get this all together, one would take the bpm and the time signature. Example:
Time Signature: 4/4
BPM: 120
means 120/4 = 30 bars per minute, or 60seconds/120beats = 0.5 seconds per quarter

Time Signature 6/8
BPM: 120
Two 1/8th are one quarter, so 240/6 = 40 bars per minute, or 60/240 = 0.25 seconds per eigth

etc.

PPQ means pulses per quarter. So this is a relative number, because the length in time of a quarter note differs depending on the bpm. In the above examples, let's assume a ppq of 960 (that number is dependant on the host daw's capabilities and the host user's decision). Now the resolution of a quarter note would be represented by 960 ticks (pulses) within 0.5 seconds, a tick per (0.5 /960) = 0.00052s

tulamide wrote:Forget about the 1-bar, the base here is 4-bars! You really make it too complicated

The unit we're working with is bars, not "4-bars."

To sync an LFO, we start by calculating the LFO rate in Hz such that it makes one cycle in one bar. Then, we can change the rate of the LFO in "bars" simply by multiplying the original LFO rate by the reciprocal of the number of bars.

1 bar = 1 * rate
4 bars = 1/4 * rate
1/4 bar = 4 * rate

See how simple that is? Multiplying those values by 4 doesn't do anything for us... it doesn't result in beats or anything. Unless of course there's some need for it in the code that I don't know of (I couldn't really follow the code just by glancing over it). That's why I'm asking why it's like that.

Perfect Human Interface wrote:

tulamide wrote:Forget about the 1-bar, the base here is 4-bars! You really make it too complicated

The unit we're working with is bars, not "4-bars."

To sync an LFO, we start by calculating the LFO rate in Hz such that it makes one cycle in one bar. Then, we can change the rate of the LFO in "bars" simply by multiplying the original LFO rate by the reciprocal of the number of bars.

1 bar = 1 * rate
4 bars = 1/4 * rate
1/4 bar = 4 * rate

See how simple that is? Multiplying those values by 4 doesn't do anything for us... it doesn't result in beats or anything. Unless of course there's some need for it in the code that I don't know of (I couldn't really follow the code just by glancing over it). That's why I'm asking why it's like that.

I give up. I just wanted to explain you, where the numbers derive from, but you don't want that to be true. If you would take the time to calculate the dsp code, you'd see, that Nubeat7 based it on a unit of 4 bars. Since you don't accept that, it's no wonder, that you are so confused. I can't help any further, I'm afraid