Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Probability Functions Changed?
#1
Hi!
So this is definitely not game-ending but it something has changed with the probability function that changes how many of my tracks in NerdSEQ are written. If it's not a bug, it would be good just to understand how I should be track this stuff now. I'm running 1.19.

My issue is that, in previous versions, I could place a probability (either trigger or CV) before a note and then return to 100% probability right after and it would only impact that step in between. Now, it seems that when I do so, it doesn't affect the steps within the "probability zone" but actually the steps after. See below. In that example, often E (step 10) will receive the probability hit and not 7 as intended (and did with previous versions.. 1.14 for sure). Probability seems to have just gotten more unstable. 


1 C# ---
2 --- ---
3 --- ---
4 C# ---
5 --- ---
6 --- PRTR 3E
7 D#
8 --- PRTR 7E
9 ---
10 E

Really I use this mostly for creating interesting kickdrum lines. This way of tracking still works for modulation (i.e. setting a modulation number before the intended impact and then reverting to original value right after.

My question is - is this intentional? It seems very hard to track this way. Ideally, I would prefer to just put the PRTR on the step that I want to apply the change to. Best case would be to have a PRTR that only triggers once but I know that wouldn't be useful for most people.

Anyway, if this isn't a bug, let me know. I would just like to know how I should change my tracking habits to accommodate for this.
Reply
#2
I moved it to this thread as it is not a crash situation.

I see some inconsistency in this report, so i am not sure if things are well or not.
First, the probability situation didn't change since a while, not sure right now if they are any differences between V1.14 and V1.19 at all (i can't check it right now).

Normally a probability setting starts with the step where you set it, so the chance that the same step hits the probability is there.
In your example you have notes but add a Trigger probability. Trigger probability is for the Trigger column, not for the note column.
With 3E you set a 62 % chance that the triggers in the trigger columns (and they must be triggers inserted there) trigger or not. I don't get the PRTR 7E as 7E is not between 0 and 100% and i don't even know how you can insert it. 64 would be 100% in your case.

So if there would be triggers on either step 6 or step 7, they would be triggered in 62% chance.
Step 10 with E is not related anymore to the probability as you (if you meant 64 = 100%) turned the probability off, but also, the note is not related to it either.
Maybe you can get a bit into detail and/or make a screenshot and let me know what you would expect but what it doesn't do.
I am not aware of issues with it currently and i also played alot with my liveset lately enabling and disabling probabilities in different ways and it still seems to work well.
Reply
#3
Sorry, I realize now how confusing that all was! I'll take some images and video and post again here as soon as I can. Thanks
Reply
#4
Ok - shot a little vid to better explain what I explained very poorly before (sorry!). It's still acting not as I would expect it to. If you need I can send the firmware but it's on 1.19. thanks for any help!

https://youtu.be/lN5FYUakz1I
Reply
#5
Ah yes thank you!

In the first place i thought that this is not good and a bug.
But then i tried myself and playing around with it and some logic i know it is correct! Nothing really wrong here.

So what happens:
You have notes filled in here! The Probability for the trigger only looks at the trigger column and doesn't care about the Note column and so the other way around. What happens here: The Probability for the trigger is indeed turned on when you turn it on. When the trigger plays, all is fine, it was not a probability situation. Also the next trigger below just plays as it should be.

If the first trigger (from the trigger column!!!) doesn't play cause of the probability, then the gate is still being set because of the note autogate function!!!
So the trigger which then always plays is then either a trigger from the trigger column or if the probability happened a gate from the note column.
And if the gate was set, then of course the new note and trigger below doesn't take effect, because the gate was already on! So the probability is already off again, but no effect because you change from a gate set to also a set situation.

You can either include a Kill000 on the step where the probability is or remove the note and all will be fine.
Also, you can turn the probability also on the same step on where you want the probability to take effect, no need to turn it on one before.

I have to say that this is worth a discussion if this makes sense or not. The probabilitys are especially for columns only. And the trigger column is in the most cases seperated from the note column. I remember the idea that either the Kill000 or if something is filled in in the trigger column should always overrule the autogate. But it is not implemented yet for the trigger.
I will start a poll if this should be the general behaviour or not....

Thanks for the report.
Reply
#6
Thanks so much for looking in to this. I think I'm having a hard time understanding but.. let me know if I got it haha. Basically it's because of the autogate function? I.e. if I were to turn that off, it would no longer work this way? I'm asking bc I remember PRTR functioning different before and perhaps it was because autogate functioned differently?

I guess I do find the functionality confusing but I'm happy to work with it however you and the community would prefer! As you said, maybe a poll is in order. If it were up to me, I'd prefer to keep it as simple as possible to avoid confusing operation like what the video showed. I.e. the TR and PRTR would supersede anything in the note column. I'll give it a shot again tonight and report back. Thanks again for your help in understanding this!
Reply
#7
Yes, basically it's because of the filled in note it does 'autogate'. And the reason that the 2nd trigger doesn't come then is because the gate is still on.

I will think further about this and create a poll.
Reply
#8
(07-08-2019, 01:54 PM)XORadmin Wrote: Yes, basically it's because of the filled in note it does 'autogate'. And the reason that the 2nd trigger doesn't come then is because the gate is still on.

I will think further about this and create a poll.

Thank you!! Greatly appreciate it. I'll try playing around with it in the meantime.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)