# Tables to play notes and increase round robins



## jdawg (Sep 16, 2013)

Hey
Im making a tables to play some notes, but its is bypassing my scripted round robin. is there a way to make the table increase the round robin aswell?

Ive tried a few things, but it sadly doesnt seem to be working



> {SEQUENCER}
> ignore_event($EVENT_ID)
> while ($NOTE_HELD = 1)
> if (%Poly_Seq[$Stepper] > 0)
> ...


----------



## mk282 (Sep 16, 2013)

You don't seem to have disallow_group() and allow_group() after that play_note(), which is probably why RR isn't working (if you did each RR in individual group, which I guess you did)


----------



## Mike Greene (Sep 16, 2013)

In a semi-related question, I've always done all my allowing and disallowing *before* the play_note(). Mario, I noticed that you used the word "after." Does this mean it doesn't matter whether (dis)allow commands come before of after the Play_note commands? (Assuming there are no "wait" commands in the middle, of course.)


----------



## mk282 (Sep 16, 2013)

Oh right, I meant before. AFTER, you use set_event_par_arr().


----------



## Big Bob (Sep 16, 2013)

Actually, I don't think it matters does it? IIRC, none of the actions take place until the callback exits or pauses. And then, things like group enable would be performed ahead of note-on. Or, am I not remembering this right? :roll:


----------



## andreasOL (Sep 16, 2013)

Big Bob @ Mon 16 Sep said:


> Actually, I don't think it matters does it? IIRC, none of the actions take place until the callback exits or pauses. And then, things like group enable would be performed ahead of note-on. Or, am I not remembering this right? :roll:



Hmmm...I hope it matters at the time a play_note is executed. How would one start multiple notes from different groups otherwise...

Andreas


----------



## Big Bob (Sep 16, 2013)

Good question Andreas, maybe I've been smokin' something again that I shouldn't have :lol: 

But, in this case, aren't the various group enables issued with separate IDs?

When I get a chance, I'm going to try to find my 'notes' on this to see why I have this remembrance.

Meanwhile, maybe just ignore my post until I get my act together.

Rejoice,

Bob

*EDIT: Well I found my very old notes on this and I'm not sure I fully understand what I scribbled* :lol: 

But, here is my current evaluation. If one is trying to control the group for the note causing the NCB, there really is no before or after. However, for any new notes generated in the NCB, the group allow would have to *follow* the note because you wouldn't know the note's id until you have generated it. But, it appears as though the disallow(-1) has to be positioned* before* the play_note.

Can anyone confirm or refute this?


----------



## polypx (Sep 16, 2013)

This works as expected, so I think the order is important if using the basic allow disallow:

on note
ignore_event($EVENT_ID)
disallow_group($ALL_GROUPS)
allow_group(0)
play_note($EVENT_NOTE, $EVENT_VELOCITY, 0, -1)
disallow_group($ALL_GROUPS)
allow_group(1)
play_note($EVENT_NOTE +7, $EVENT_VELOCITY, 0, -1)
end on


----------



## Big Bob (Sep 16, 2013)

Hi Dan, long time no see!

The thing that puzzles me a little bit is the meaning of the standard allow_group action. I always sort of thought that it was 'tied' to the current EVENT_ID.

But, your example would imply that it ties itself to the next play_note id ??? Or, perhaps to the first note created after the last disallow_group? For example, have you tried moving just the allow_group(0) and allow_group(1) without moving the disallow_groups to see if that changes anything?

I guess I'm going to have to 'dig in' again to fully characterize this thing. Hopefully I can write clearer notes this time for my future reference :lol:

EDIT: Never mind the suggested test. I just tried it here and I guess if its anything I hypothesized it must be the former (ie that the standard allow/disallow associates itself with the next note event created (or something similar to that). I'd really like to understand this more completely so, when time allows, I'll try to run this into the ground (again) :? Unless in the meantime, someone posts a really detailed analysis of how this all works :roll:


----------



## polypx (Sep 16, 2013)

Hey Bob! 

I don't think the basic allow/disallow ties itself to events at all, I feel like it's absolute... it opens and closes the gate, as it were, in "real" time. Hmmm... I can't seem to find the right words here at all. 

The set_event version of allow disallow of course is tied to events.

cheers, Dan


----------



## mk282 (Sep 17, 2013)

Basic allow/disallow doesn't tie to event IDs - that's where you use set_event_par_arr() along with $EVENT_PAR_GROUP_ALLOW.


----------



## andreasOL (Sep 17, 2013)

Bob, you are right in the context you described it in...I was too focussed on notes started by play_note in the NCB (or the RCB). If the original event is not ignored then a disallow/allow that is effective at the end of the callback affects the implicite play_note that happens after the callback.

Cheers,
Andreas


----------



## jdawg (Sep 17, 2013)

(o) this thread is getting interesting


----------



## Big Bob (Sep 17, 2013)

mk282 @ Mon Sep 16 said:


> Basic allow/disallow doesn't tie to event IDs - that's where you use set_event_par_arr() along with $EVENT_PAR_GROUP_ALLOW.



Yes Mario, but when NI added the $EVENT_PAR_GROUP_ALLOW mechanism to the hopper, it caused me to wonder if the basic allow/disallow stuff wasn't also related to the currently active note id (namely the one in EVENT_ID). This then prompted a short study of the behavior. The problem is the details have now escaped me and apparently, I was left with some kind of incomplete and inaccurate remembrance. That's the problem with having an old brain (you young guys wouldn't know anything about that problem) :lol: 



> Bob, you are right in the context you described it in...I was too focussed on notes started by play_note in the NCB (or the RCB). If the original event is not ignored then a disallow/allow that is effective at the end of the callback affects the implicite play_note that happens after the callback.





> Hey Bob!
> 
> I don't think the basic allow/disallow ties itself to events at all, I feel like it's absolute... it opens and closes the gate, as it were, in "real" time. Hmmm... I can't seem to find the right words here at all. Wink
> 
> ...



Andreas and Dan, probably all of the above is more or less true under the right conditions but we really need the complete picture. And, so far, no one has really presented a rigorous analysis. Just a lot of 'for this you do this' and 'for this other thing you do that', etc.

Has anyone actually done a detailed analysis of this? If not, I guess one of these days I'll have to author another one of my infamous Study and Report docs. :lol:


----------



## jdawg (Sep 18, 2013)

soo i have it working with my round robins scripted but it is incrementing round robins after every iteration of the table is read, which is great for playing a single note not so good when i am playing chord. 

before this table i had scripted round robin allow groups so that they only incremented upon the release of a note. Meaning chords did not sound as repetitive as the round robin would only increment on the playing of the same note twice, is there a way I can have it act like that within the table??

Appreciations as always





> ignore_event($EVENT_ID)
> while ($NOTE_HELD = 1)
> if (%Poly_Seq[$Stepper] > 0)
> play_note ($EVENT_NOTE],%Poly_Seq[$Stepper], 0, -1)
> ...


----------



## jdawg (Sep 20, 2013)

AND



> ignore_event($EVENT_ID)
> while ($NOTE_HELD = 1)
> if (%Poly_Seq[$Stepper] > 0)
> play_note ($EVENT_NOTE],%Poly_Seq[$Stepper], 0, -1)
> ...



i can get this working really well repeating play notes, but I want it to let go of the note before it start again, but having

note_off($EVENT_ID) inserted in the above, breaks the NOTE_HELD = 1 and stops the entire sequence. is there any other way to get round this?


----------



## jdawg (Sep 21, 2013)

Been trying to get this funcitoning to work, 

if i use a fade_out and the end of the while it works, but then it does not work with my release triggerings. 

is there a funciton to call so that i can have this while loop release the sustains ?


----------

