Randomizer / Pitch percentage?


#1

Hey. I have been using Pyramid for a few months now and I must say that I am reasonably satisfied so far. Yet I notice that there are a number of illogical settings, such as the RANDOMIZER / PITCH. Why should RAND + and - be set as a percentage and not as a number of notes? For a musician this is not a common line of thought. And how should I interpret this percentage? Should I then assume a percentage of the MIDI note number or a percentage with regard to the entire range, where 1% stands for 1.28 notes?


#2

I think every Randomizer function need an attenuator knob in the setting


#3

This is a good question and I am curious about the true answer as well. Don’t know if Squarp actually still checks the forum, but I would consider an answer from anyone other than the official Squarp support to be merely speculation.

That said - here’s my speculation.

I think of that ± percentage in the same way that it sounds like Sinapsya does - as an attenuation of the offset that the randomizer wants to apply. Example:

Let’s say I have my “Rand-” set to 10% and my “Rand+” set to 50%. And then let’s say I hit note 48. The RNG now generates a random offset to add to my note. The parameters to that random call are just my speculation, but let’s say that it basically chooses a random number in the range of (-48, 79) [since I hit note 48, these are the boundaries that would cover the full range of 0-127 MIDI notes.]

So let’s say that the number it produced was -21.
Since this is a negative value, my 10% negative attenuation gets applied, so we multiply -21 * 10% and get a -2.1.
So that would round to a -2 and the resulting note that is sent to the instrument is 48 - 2 = 46

Now, let’s say I hit 48 again and this time, the random number that it generates is +74.
Now my 50% positive attenuation is applied, so 74 * .50% = +37.
Which means that the resulting note that will be played is 48 + 37 = 85.

But this logic really all hinges on the range of the random value that it generates in the first place. It could theoretically be doing something a bit more “dumb” and always generating an offset in the range of (-127, 127), regardless of what note you hit. So if you had hit, say, note 30 and it generated a -120, you would ultimately be sending a note of 0 if your (Rand-) was anything higher than 25%. That approach would be significantly less “musical”, as it would cause frequent wide swings in pitch or volume.


#4

I have it on my “when i get around to it” list to try different percentages and see what the resulting note values might be.


#5

This is not a scientific test.

I set up the Randomizer and monitored the output. This is just observable via note data only. I didn’t dump all the data into a spreadsheet, although I used a spreadsheet and a notebook to track my data (notebook for raw notes/observations/challenges, and the spreadsheet for destination info to try to discern a pattern).

I only tested for the lowest percentages of the Randomiser first, then created an assumption, then tested with higher values. Without a system for capturing and collating the data, it’d be a pain in the butt for really high Random percentages because +50% is a lot of notes.

I noticed that one ‘click’ of the Encoder did not always equal one percentage increase in the Random %. More on that later. Incidentally, the first click did not change the Rand % for me - it stayed at 0%, although it does yield an actual change in Pitch.

I did notice for the first 12 clicks that one click of the Encoder yielded one more note. That is, using Note 0x0C as my base note (C0/0d12/etc) and clicking the Encoder ONCE (which did not indicate a change in percentage incidentally) yielded notes 0x0C and 0x0D.

I observed this behaviour as consistent all the way through 12 clicks.

Using this as initial data to test that we might be able to put a firm foot on assuming the relationship as one click = +/- 1 note, then I pumped it up to 30 clicks.

As predicted, notes varied from 0x0C(0d12) to 0x2A(0d42) - a difference of 30.

Now, as we know in MIDI there are only 128 notes (LOL), 30 is 23.43% of 128 and, curiously enough, the Pyramid shows that 30 clicks as RAND+ 23%.

This is just a quickie, low pressure, observable data only test. However, I think it shows what might be happening on the OS side of things (subject to change w/out notice, of course). You are welcome to your own tests and it’d be festive to continue the testing/review/etc, but for me:

Each click = 1 note
% is based on the note spread against the 128 MIDI Note range.


#6

I like the calculations and experimenting, but I think I’m with @CreepyPants in this case… 1 click for a note. I think I’m going to enter a request at Squarp to change the percentage to a note amount, and do that at every functionallity where it applies. Calculating (… or counting clicks) is not difficult but it’s very annoying when I want to make music. A user interface should always show official definitions instead of numbers that need calculations. Calculations and counting clicks are a job for a computer. :smile:


#7

So… basically the percentage values dictate the boundaries of the random number generation function, rather than an attenuation that is applied after the random number is derived. This makes sense, as these boundaries were exactly the question mark that screwed up my theory.

To be honest, at first CreepyPants’ findings struck me as weird and annoying because of the fractional values. But this implies that a Rand+ value of 10% means that it will produce a note that is within roughly one octave of the note you actually programmed, right? If that is the case, I think that’s the rule of thumb to live by and should be easy enough to remember.

Note to self: never increase these random percentages by more than 10% either direction.

So if I have my Randomizer set to Rand- = 10% and Rand+ = 10%, then a note programmed as C4 could be any note between C3 - C5. Slap a scale effect on there to keep it in key, and that’s pretty much the maximum range I would ever want a randomizer to go with my input. Often less than that, frankly.

Oh and if this is the case, I totally agree with your original point, OpenMind - using percentages here is a poor user experience that only serves to prevent us from understanding the implications of the values we select.