+- XOR Userforum (https://forum.xor.eu)
+-- Forum: Products (https://forum.xor.eu/forumdisplay.php?fid=3)
+--- Forum: NerdSEQ (https://forum.xor.eu/forumdisplay.php?fid=6)
+---- Forum: General Questions (https://forum.xor.eu/forumdisplay.php?fid=17)
+---- Thread: Accumulate, Metropolix style? (/showthread.php?tid=1075)
RE: Accumulate, Metropolix style? - XORadmin - 04-06-2021
(04-06-2021, 11:35 AM)mgd Wrote:(04-06-2021, 11:06 AM)XORadmin Wrote:(04-06-2021, 10:52 AM)mgd Wrote: I tried to insert SPFX 011 while tables 01 and 02 were playing and removed the SPFX 011 at the end. That results in table 01 and 02 skipping every other step. The HP 00 is still not executed.
Are you really sure the project does what it should and that the tables are indeed working correctly?
How could I make the HP 00 in table 01 and 02 to get executed?
From what I see any SPFX 011 moves tables 01 and 02 forward no matter what. I do suppose the same is true for table 00 but since that does nothing I can't tell.
[I want an SPFX 011 that specifically targets a table and possibly incr/decr the current position in the table by more than 1, but that is for a feature request once I'm more comfortable with the tables.]
Kind regards,
Michael
When table 00 is for expample set to Table Step 3 and you switch to Table 01, then 01 is also on step 03 if in loop mode (or step 0 if resync). There is no own table counter for each possible table in each track. So the behaviour here is right. No HOP is executed because always the SPFX 011 is happening when table 00 is active.
Have you actually tried to run the project?
Also may I point you towards a test I made:
(04-06-2021, 10:52 AM)mgd Wrote: I tried to insert SPFX 011 while tables 01 and 02 were playing and removed the SPFX 011 at the end. That results in table 01 and 02 skipping every other step. The HP 00 is still not executed (at least not that I realized it)
I'm not sure that what I do is correct, but the tables don't behave the way you describe they should... or I simply don't understand you.
To be clear:
I think they almost behave the way I expect them to. My only issues are thatCurrently my understanding (based on my experiments - may be completely wrong) is
- HP 00 is not executed and I have found no way to do so
- the initial setting of the tables is executed twice, i.e. it seems the first SPFX 011 initializes all position pointer (or however you call them) to 0 and thus results in table position 0 being executed twice
- all tables set to SOURCE PTN-SFX share a position pointer, i.e. they are not "moved"/played independently [I would want them independent --> possibly feature request material; required for Accumulate like functions via tables and useful for all sorts of generative music]
- HP 00 [possibly HP in general but I have not tested that] is ignored for tables set to SOURCE PTN-SFX
Basically I wish to understand what's happening and why
Kind regards,
Michael
Yes I did try your project before I answered in the first place and I don't see any issue with the sequence. It behaves as I expect it to.
Tables in a Track share 1 position pointer and that will stay like this (so I don't give independent pointers a big chance, since I think they are hard to manage by users and understanding a sequence would be impossible. It's now already difficult sometimes). If you switch to another table, the pointer doesn't change except for if you set it to resync. A new step is executed in your case with the SPFX command. In your project when this command is being executed it never plays table 01,02 or 03. (you can see the active table for this track in the pattern screen).
- HP 00 [possibly HP in general but I have not tested that] is ignored for tables set to SOURCE PTN-SFX
It works as advertised and executes the HOP. I just tested that.
- the initial setting of the tables is executed twice, i.e. it seems the first SPFX 011 initializes all position pointer (or however you call them) to 0 and thus results in table position 0 being executed twice.
As with clocking in general, a step is executed when a tick/clock is happening. With the table you use, there is no clock in the first place but the first clock comes on step 14 which is then also the first execute. They are also fine here.
RE: Accumulate, Metropolix style? - mgd - 04-06-2021
(04-06-2021, 12:04 PM)XORadmin Wrote: - the initial setting of the tables is executed twice, i.e. it seems the first SPFX 011 initializes all position pointer (or however you call them) to 0 and thus results in table position 0 being executed twice.
As with clocking in general, a step is executed when a tick/clock is happening. With the table you use, there is no clock in the first place but the first clock comes on step 14 which is then also the first execute. They are also fine here.
Hmm.
I did the following tests:
I moved the SPFX 011 in the pattern from 0E to 0B (while 02 is still active).
Now playing gives me the untransposed line twice before transposition starts.
I then changed the tables 01 and 02 as of my project such that line 00 (no transpose) was removed and played it.
It now plays the first transposition line twice and then moves on.
That seems at least unwanted. When initially the effective table position is 0 then applying SPFX 011 should move this on forward instead of initializing it to 0 (that's what it seems to me right now).
As an afterthought:
What triggers the execution of a HP?
Let's say there is a HP 00 on step 03 of the table. Is it executed upon executing/playing step 03 or is it executed when that table is active and plays step 02 and then a SPFX 011 happens?
Or phrased differently:
Is HP executed when the position pointer of the active table is moved and the new step of that table contains a HP?
What happens when there are RND HP on each step?
Is at most one HP performed per tick/clock or could I create an infinite loop?
Kind regards,
Michael
PS: I'm not trying to be PITA. I'm honestly interested in understanding how these things work
RE: Accumulate, Metropolix style? - XORadmin - 04-06-2021
[quote pid='6565' dateline='1617713774']
I moved the SPFX 011 in the pattern from 0E to 0B (while 02 is still active).
Now playing gives me the untransposed line twice before transposition starts.
I then changed the tables 01 and 02 as of my project such that line 00 (no transpose) was removed and played it.
It now plays the first transposition line twice and then moves on.
[/quote]
Trust me, this is allright. You are manually adding ticks, you activate tables already and the first step needs also a tick. The transposition is active, It doesn't execute the Hop or FX yet. It is important that the transposition is already active, else even regular clocked tables wouldn't work well.
Tables and real player run on it's own (it has to). If a table is started, it gets the tick after the player did it's job. But you want the note from this step to be transposed already, so it is active but executed after the regular player (if a tick was there).
If the last executed was for example Step 02 and on 03 is a HOP, then a new tick would execute the hop = set the pointer to like 00.
All set to random will execute the HOP after a tick at first and sets the pointer to a random position. The rest of the new step is being executed. No infinite loop here since the HOP command has already been executed in this run.
RE: Accumulate, Metropolix style? - mgd - 04-06-2021
Ok.
I think I've adjusted my understanding of how clocking of tables works [enough] to make things work the way I want them to work. Except for the realization that all tables share their position pointer. I honestly had thought they are independent and considered that part of the power of SPFX 011.
I still think that individual position pointer per table would be an extremely valuable addition as it allows for all sorts of evolving patterns to happen (and I could get rid of all my external 8-step sequencer... tables are more powerful anyway
). And it would turn tables into real sequencer inside the sequencer.The concern w/r to added complexity IMO could be dealt with by providing extra commands to move the position pointer of a particular table, possibly add a "reset all table pointers to 0" command (for SYNCH). The current SPFX 011 command would then be renamed to "increment all table position pointers" (or something to that end), i.e. all existing stuff remains unchanged.
I understand that the existence of complicated functionality will also lead to people trying it and being frustrated by "it not working the way they think it should". I do hope that this could be prevented by proper documentation. If it would help convincing you to make that happen I'd certainly be willing to write up use cases and example HOW TOs for this. Basically along the line of the stuff I wrote in this thread (w/o the mistakes due to me not understanding how things work
)Kind regards,
Michael
RE: Accumulate, Metropolix style? - XORadmin - 04-06-2021
(04-06-2021, 01:56 PM)mgd Wrote: Ok.
I think I've adjusted my understanding of how clocking of tables works [enough] to make things work the way I want them to work. Except for the realization that all tables share their position pointer. I honestly had thought they are independent and considered that part of the power of SPFX 011.
I still think that individual position pointer per table would be an extremely valuable addition as it allows for all sorts of evolving patterns to happen (and I could get rid of all my external 8-step sequencer... tables are more powerful anyway
The concern w/r to added complexity IMO could be dealt with by providing extra commands to move the position pointer of a particular table, possibly add a "reset all table pointers to 0" command (for SYNCH). The current SPFX 011 command would then be renamed to "increment all table position pointers" (or something to that end), i.e. all existing stuff remains unchanged.
I understand that the existence of complicated functionality will also lead to people trying it and being frustrated by "it not working the way they think it should". I do hope that this could be prevented by proper documentation. If it would help convincing you to make that happen I'd certainly be willing to write up use cases and example HOW TOs for this. Basically along the line of the stuff I wrote in this thread (w/o the mistakes due to me not understanding how things work
Kind regards,
Michael
I think one pointer per table (per track...each track got it's own pointer of course) is really already complex enough to handle. Also the tables in general are a powerfull tool, combined with FX etc they are endless possibilities. Also regarding to the accumulate effect, something like that can be done. Not exactly, not everything. But parts of it and much more beside it. There is actually one little thing I added to the FX with the latest Release Candidate and that is that MOD and CV are not only pitches anymore, but can now also be notes. This includes now also notes into the +-*/ functions (and these also with or without the use of tables).
As for the rest, I had second thoughts about the Accumulate functions in the Metropolix and I don't think it will be high on my 2do list. I understand the enthousiasm when a new sequencer comes out which has function X or Y. But the NerdSEQ is it's own thing and the concept is totally different and this is definitely not a killer feature but more a tool to make limited loops more interresting (no offense to metropolix, I really like what I see and for what it is it is top). The NerdSEQ is able to make complex sequences and generative things are added more and more.
And there is still enough to come on my list which is more interresting for the NerdSEQ ecosystem and for the sequencer in general.
RE: Accumulate, Metropolix style? - mgd - 04-06-2021
I'm certainly not here to advocate the Metropolix or it's Accumulate function. AFAIC it is less powerful than tables [could be] and the idea is not new at all either. The UI seems nice though. For me Accumulate has just been the trigger when I realized it effectively does Arpeggios on a per note base.
From what I've seen it seems difficult to construct meaningful evolving pattern, something I clearly see I could do with tables that allow me to define arbitrary and musically useful sequences (NerdSEQ) as opposed to having to find a building rule (Metropolix) for my sequence.
But hang on...I get differently "clocked" tables when I put them on different tracks?
That of course brings me a long way towards what I'm looking for
I will have to merge them outside (of the NerdSEQ) then, but that's what I have my various Adder bought for anyway
There definitely seems to be quite a lot of hidden knowledge regarding tables that is not in the manual and not easily accessible by playing with them.
Kind regards,
Michael
RE: Accumulate, Metropolix style? - XORadmin - 04-06-2021
Quote:But hang on...I get differently "clocked" tables when I put them on different tracks?
Yes, each track has it's own table pointer. So you could have table 00 running on multiple tracks and each on it's own steps.
The table tick SPFX adds only a tick on this track.
RE: Accumulate, Metropolix style? - mvdirty - 04-06-2021
Okay, after following along with the recent replies I’m back to where I was originally, and should not have doubted myself in the first place.
(This table state management is, by the way mgd, exactly why I framed the very first “challenge” in terms of moving two steps each in a different direction, as I suspected we’d hit that limit right away.)
I’m still going to be playing with both modules this week, and will pipe up about anything interesting I see that could translate nicely into the NerdSEQ worldview (or at least my understanding of it,) but I won’t be placing quite the same priority on going deep during these next few days. I only have today, tomorrow, and Thursday off to focus on music, and I’m sure it’s going to go fast.
RE: Accumulate, Metropolix style? - mgd - 04-06-2021
Well, I managed to get the first "challenge" working by means of using two tracks which does not seem an economic solution. If anybody is interested I'm happy to share the project. My solution also involves an external OR function for the Trigger/Gate.
However what can easily be done are all types of "Note Arpeggios" (I find that a better word than Accumulate) with equal length or where the lengths are multiples of each other. And then you have more flexibility when using tables than by giving an increment. Arguably more complex to setup too (flexibility comes at a price
)For any new length (i.e. a length not covered by the above) for such a "Note Arpeggio" you'll have to sacrifice a whole track (at that time) and the setup requires quite some attention to not get it wrong. So that's more a proof of concept at best
[if we had individual position per table instead...
]I'm still very interested to learn about other things you may find that I'm not yet aware of though.
Kind regards,
Michael
RE: Accumulate, Metropolix style? - XORadmin - 04-06-2021
(04-06-2021, 06:30 PM)mgd Wrote: Well, I managed to get the first "challenge" working by means of using two tracks which does not seem an economic solution. If anybody is interested I'm happy to share the project. My solution also involves an external OR function for the Trigger/Gate.
However what can easily be done are all types of "Note Arpeggios" (I find that a better word than Accumulate) with equal length or where the lengths are multiples of each other. And then you have more flexibility when using tables than by giving an increment. Arguably more complex to setup too (flexibility comes at a price
For any new length (i.e. a length not covered by the above) for such a "Note Arpeggio" you'll have to sacrifice a whole track (at that time) and the setup requires quite some attention to not get it wrong. So that's more a proof of concept at best
[if we had individual position per table instead...
I'm still very interested to learn about other things you may find that I'm not yet aware of though.
Kind regards,
Michael
What are you trying to do exaclty?