OT Feature Requests Thread (active)

Pattern length as LFO destination would be absolutely amazing !!

3 Likes

well cc’s are sent but you can’t dump all parameters at once. thinking of a remote where you can dump the current state of all dials to reflect the settings of the Octatrack.

do you not use track 8 as a master track? i have mine midi mapped to LCXL and this isn’t any sort of problem.

i’m wondering if the MANIFOLD app might be able to do this? might try


whats that?
well you need to talk to OT and bring it to send the values. for now i don’t know if this would be possible somehow.

But that’s exactly what the CC 61 does: after you’ve sent it to the OT you get all the actual audio parameters back (as a batch of single CCs). IMHO this way is much easier for syncing external controllers to OT’s internal state than a custom formatted sysex message (which would need special interpretation on the receiving side).

2 Likes

Just had a chance on OT to check quickest way to experience the mute behaviour within arranger:

Empty project

Assign a looping sample to a static or flex on track 1

Put a trig on every step of pattern A01

Go into arranger and use func+down to insert the default row (which is A01 length 16)

Func+down again, but set this row to loop the row above infinitely

(anti-clockwise turn under PAT, click right, turn anti clockwise to get ‘LOOP: 000/infinity’)

Double stop and press play to begin arrangement

(You hear just the start of your loop trigging on every step)

Click right to get to the mute column (M) of row 1

Press Enter

Press trig 1 to “mute” T1

It doesn’t mute the audio (you hear your loop playing out after the bar has finished)

What’s happening is that the last trig is playing out, subsequent trigs are ignored until you unmute. You won’t get silence within this ‘muting’ scenario

Ok i understand what you mean now but it doesn’t seem usable practically in live neither that it is programmable within the arranger.

I’d say it is a side effect but it is not meant to be used that way.

Repeat with a short non-looping sample with long effect tail to further compare with standard track mutes.

My speciality

1 Like

Don’t forget the « not usable » :wink:

Don’t forget the OP didn’t ask about performance :wink: They wanted to ‘mute trigs not audio’ and you can use the arranger to program exactly that

Nonetheless, one ‘usability’ tip for using the arranger in performance:

Create rows with the mutes you need and pair them with a descriptive REM statement one the row above . Such as “MUTE T1” or “MUTE KICK”


Then move cursor onto the written description. The sequencer spends no time on REM rows, going straight to the mute state programmed for each.

Trying that now. It’s cool.

You lost me here. From what i understand, you suggest to mute trigs on the fly since only muting tracks is programmable.

I’m afraid i don’t get that part (what moving on the written actually does).

i am sory to say but i completely agree that LFO is ok the way it is

maybe only thing would be great to have other LFO params(pmtr,wave,mult,trig) on MIDI CC that would give external and there for direct control over those parameters

best regards

I probably summed it up a bit hurriedly there! Will try to explain better when I get a chance

Like this :slight_smile:

You can set a row to INF - meaning it will play until you manually move to another row and press yes.

You can set different mute states for each row.

You can use REM to easily identify what each row does.

So, you set up a bunch of rows with different mute settings, then move between them by select and yes, in a performance setting.

Example:

Row 1 REM 234
Row 2 mutes tracks 2,3,4
Row 3 REM 258
Row 4 mutes tracks 2,5,8

Etc.

You can give REM more meaningful name like intro, drop, chorus or whatever.

3 Likes

Ok i got this but did not understand the connection with the trigs mute trick he proposed.

Just that this way you don’t cut off audio like you do with standard track mutes. Because it mutes trigs you preserve things like reverb trails, the ends of ride samples, delay tails etc.

@darenager great summary

I’d forgotten about INF length ( I was using an extra LOOP line each time - your approach much less clutter on the event list)

I worked out a new way to trigger LFO behaviour with the arranger too. Will detail when I get a moment (basically - copy a 1 bar pattern across two bars - have an LFO event like a fade, set to (I think) ‘sync one’ - then you loop only the second bar using beat offset within arranger - then trigger the first bar whenever you want to LFO event to occur)

Then I got into triggering tempo changes with the arranger - but it always causes this crash


Think I’ve found another bug but no more time on OT argh

Edit : a project crashing this way has its tempo set to 30 after power cycle. Which I guess also suggests the tempo events are the culprit

Edit 2: the crash happens again after power cycle but not if I remove the tempo changes from the arranger

Got a feeling so few people use the arranger and even less for BPM that it might just be as simple as “tempo changes in the arranger crash the OT” Edit - no not that simple, must be combination of things, tricky to pin down

1 Like