Expose I2C/Multi Poly Round Robin as a Mappable Source/Destination

[jeff.r.day]

Currently, there is a "Midi -> MOD" option on Modular track type.

In projects using only I2C/Multi track type, however, the velocity coming in from MIDI doesn't get routed through to the MOD outputs, but it would be nice to be able to make the Velocity go somewhere appropriate during live performance (as a pass-thru.)

I understand there are two reasons for this not to work:

1. There is no where in the I2C/Multi pattern to store the modulation values for each note.
2. The Destination in the track setup only specifies pitch and gate, for example CVGA, and not CVGA+MOD, so there's no instruction even of where to route a mod value to.

The obvious solution is that this could be handled through Mappings, except there's no way to keep track of where the I2C/Multi Poly round robin is currently pointing.

It seems like if the Round Robin were explicitly exposed in the mapping screen, and there were simply six internal track variables where the Velocity gets stored at the same time when any one of the six Destinations is written to, then a set of Mappings could be used to copy from these variables into the appropriate spots with a mapping like this, for example:

TRCK TRK1 VEL1 ----  >  CV PTCH MOD1
TRCK TRK1 VEL2 ----  >  CV PTCH MOD2
TRCK TRK1 VEL3 ----  >  CV PTCH MOD3
TRCK TKR1 VEL4 ----  >  CV PTCH MOD4

It is critical that VELx only get filled in when that particular destination is written to in round-robin, that way the mapping can send them to the corresponding outputs (whatever they are) that go along with the pitch and gate already set.

It might be helpful to also make TRCK TRK1 RR  expose the number of the last round robin destination, then we could also write to it to reset the round robin back to zero for instance.

[XORadmin]

Currently, there is a "Midi -> MOD" option on Modular track type.

In projects using only I2C/Multi track type, however, the velocity coming in from MIDI doesn't get routed through to the MOD outputs, but it would be nice to be able to make the Velocity go somewhere appropriate during live performance (as a pass-thru.)

I understand there are two reasons for this not to work:

1. There is no where in the I2C/Multi pattern to store the modulation values for each note.
2. The Destination in the track setup only specifies pitch and gate, for example CVGA, and not CVGA+MOD, so there's no instruction even of where to route a mod value to.

The obvious solution is that this could be handled through Mappings, except there's no way to keep track of where the I2C/Multi Poly round robin is currently pointing.

It seems like if the Round Robin were explicitly exposed in the mapping screen, and there were simply six internal track variables where the Velocity gets stored at the same time when any one of the six Destinations is written to, then a set of Mappings could be used to copy from these variables into the appropriate spots with a mapping like this, for example:

TRCK TRK1 VEL1 ----  >  CV PTCH MOD1
TRCK TRK1 VEL2 ----  >  CV PTCH MOD2
TRCK TRK1 VEL3 ----  >  CV PTCH MOD3
TRCK TKR1 VEL4 ----  >  CV PTCH MOD4

It is critical that VELx only get filled in when that particular destination is written to in round-robin, that way the mapping can send them to the corresponding outputs (whatever they are) that go along with the pitch and gate already set.

It might be helpful to also make TRCK TRK1 RR  expose the number of the last round robin destination, then we could also write to it to reset the round robin back to zero for instance.

Why not using a modular track for it then?
A I2C/Multi track doesn't know any deeper Midi information as every column can only store 1 information which is note on/off only. Midi is just one possible input channel.

[jeff.r.day]

Using an entire track that will always be blank is a big sacrifice. I'm storing polyphonic chords in an I2C/Multi track for the non-live portions, so putting a Modular track in position #1 would solve the problem, but that reduces my number of usable tracks with no patterns ever being used in it. My current setup looks like:

Track 1 - Modular track currently sacrificed for this purpose alone.
Track 2 - This will be used for my drum patterns once my Trigger16 arrives (waiting on it currently.)
Track 3 - I2C/Multi track that I'm using for a solo voice, I have column 1 routing to internal CVGA 6. (This would be a Modular track if it had flexible destinations, but either type works well enough for me here.)
Track 4 - I2C/Multi four note polyphonic chord progression, routing to internal CVGA 1 through 4.
Track 5 - CV16 on NSA2 that i'm using to control a bunch of modulation parameters (6 via columns and 2 via FX) which alter the sound of my solo & poly voices.
Track 6 - CV16 on NSA2 that i'm using to control a bunch more modulation parameters (6 via columns and 2 via FX)
Track 7 & 8 - Audio (sample based)

My end goal is to get another CV16 expander on NSA1 that I will be using to modulate Morphagene and an FX module, which is what I was hoping to put onto Track 1.

[XORadmin]

Using an entire track that will always be blank is a big sacrifice.  I'm storing polyphonic chords in an I2C/Multi track for the non-live portions, so putting a Modular track in position #1 would solve the problem, but that reduces my number of usable tracks with no patterns ever being used in it.  My current setup looks like:

Track 1 - Modular track currently sacrificed for this purpose alone.
Track 2 - This will be used for my drum patterns once my Trigger16 arrives (waiting on it currently.)
Track 3 - I2C/Multi track that I'm using for a solo voice, I have column 1 routing to internal CVGA 6. (This would be a Modular track if it had flexible destinations, but either type works well enough for me here.)
Track 4 - I2C/Multi four note polyphonic chord progression, routing to internal CVGA 1 through 4.
Track 5 - CV16 on NSA2 that i'm using to control a bunch of modulation parameters (6 via columns and 2 via FX) which alter the sound of my solo & poly voices.
Track 6 - CV16 on NSA2 that i'm using to control a bunch more modulation parameters (6 via columns and 2 via FX)
Track 7 & 8 - Audio (sample based)

My end goal is to get another CV16 expander on NSA1 that I will be using to modulate Morphagene and an FX module, which is what I was hoping to put onto Track 1.

Looks like you would need at least 4 other of the major sequencers to be able to achieve the same if there was no NerdSEQ. ;-)
If you play anything on that I2C/Multi track that will always interfere with the chords you play, no?
Thought about using patches on the modular track then instead? There you can create your chords as well. So no ‚blank‘ patterns.

[jeff.r.day]

Using an entire track that will always be blank is a big sacrifice.  I'm storing polyphonic chords in an I2C/Multi track for the non-live portions, so putting a Modular track in position #1 would solve the problem, but that reduces my number of usable tracks with no patterns ever being used in it.  My current setup looks like:

Track 1 - Modular track currently sacrificed for this purpose alone.
Track 2 - This will be used for my drum patterns once my Trigger16 arrives (waiting on it currently.)
Track 3 - I2C/Multi track that I'm using for a solo voice, I have column 1 routing to internal CVGA 6. (This would be a Modular track if it had flexible destinations, but either type works well enough for me here.)
Track 4 - I2C/Multi four note polyphonic chord progression, routing to internal CVGA 1 through 4.
Track 5 - CV16 on NSA2 that i'm using to control a bunch of modulation parameters (6 via columns and 2 via FX) which alter the sound of my solo & poly voices.
Track 6 - CV16 on NSA2 that i'm using to control a bunch more modulation parameters (6 via columns and 2 via FX)
Track 7 & 8 - Audio (sample based)

My end goal is to get another CV16 expander on NSA1 that I will be using to modulate Morphagene and an FX module, which is what I was hoping to put onto Track 1.

Looks like you would need at least 4 other of the major sequencers to be able to achieve the same if there was no NerdSEQ. ;-)
If you play anything on that I2C/Multi track that will always interfere with the chords you play, no?
Thought about using patches on the modular track then instead? There you can create your chords as well. So no ‚blank‘ patterns.

Correct, the NerdSEQ is amazing.
And yes, the chords vs. the poly live playing would conflict and are used at different times in the arrangement, not at the same time.