OT Arranger issues

Hello everyone, my name is Marco and I write from Rome.
I wanted to see if is there anyone on this forum who can help me with a couple of crazy issues I’m having with the arranger.

I’ve been using the OT during my live performances for a couple of years, mostly resampling on the fly and using few patterns only. Now I’m moving on towards a new kind of performance, and me and my partner will both use an octatrack along with few other machines … and we need to use the arranger.

Here’s the issues I’m facing right now:

  • If I start the arranger from the first row, the external midi sync (octatrack is the master) is perfect. If I start the performance from another row (in case I wanna just change the tracklist of my live show … and yes I’m trying to stick to 1 arrangement only) the external midi sync I’m sending out from the OT has a very “regular” 10ms delay. I tested this re-adjusting the midi tempo compensation on Maschine. So basically, from the first row PERFECT SYNC, from any other rows, 10ms DELAYED SYNC. Ideas anyone?

  • This one is quite crazy, Two different OTs, same issue. Arrangement, when you reach bar 343, you always get the “transport bar number” like this 343.1.2 instead of 343.1.1 It doesn’t matter which pattern you’re playing, lenght etc etc. You always get this at row 343. When you perform it, on the master OT it sounds like there’s no problem (most of the times), all the other slaved machines are missing the first hit! And few times the sync was also a bit fucked up. Only from this row on. 343. We are literally going crazy, and this might make us change our mind about using the OTs for the next tour. Any ideas or similar problems?

  • When I program mutes within the arranger, sometimes the mutes are on sometimes are not. Randomly. Especially in the case when I decide to move independently along the arranger’s rows. Let’s say I wanna go back to row 11, well the mutes are not performed automatically anymore … like it happened, dunno, few minutes before when I played row 11 for the first time. Also, once you program a mute within a row, is there a way to unmute manually while the pattern is playing?

Sorry for the lenght, but we have 20 days till the next tour, and we need to decide whether to drop the OTs or not. We are so frustrated as we strongly believe on the strenght of this amazing piece of hardware :frowning:

Hope you guys can send some ideas.

Cheers.

Regarding the first two (bold) sections, I´d suggest to contact support as none of them sounds as being intentional within the OS.

Regarding mutes within the Arranger, the first thing that comes to my mind is that given your settings per track regarding sample loop (2nd playback page). You´ll get different results depending on if a track is muted first or not in the Arranger.

Example:

[ul]
[li]Track 1 muted when you start (sample loop set to auto or on), everything seems normal as it is muted.[/li]
[/ul]
[ul]
[li]Arranger unmutes track 1 within a row somewhere, everything still seems normal as it starts playing.[/li]
[/ul]
[ul]
[li]Arranger mutes track 1 again within a row somewhere, the sample will continue by itself (looping) even though that the track has stopped. This very thing can be used to your advance in certain situations, but also lead to some confusion of course.[/li]
[/ul]

Say that the sample in track 1 would be of “perfect” lenght i e 16steps with a trig at the first step. When the sequencer restarts, you wouldn´t notice that the sample playback setting in fact are set to auto or loop since you are triggering it again everytime.
However, say that the sample in track 1, still of “perfect” lenght (16steps), but you are using the maximum 64steps in the sequencer you would still (with the same settings) only need the trig to be at the first step as above. But the loop playback of the sample would then continue until the sequencer starts over after the 64th step. This is what´s potentially happening within the arranger. You are muting the track trigs, but the sample playback continues anyway.

There are settings that you can change to get other types of behaviour, but they may lead to unexpected results from another perspectives regarding pattern changes (abrupt changes of track sample playback, no effects spill-over etc). Make sure that you understand the differencies between them and what preparation/programming you´ll need to make it work within the Arranger.

Hey thanks a lot for your answer. I will try to pay attention to the things you said, but I guess it’s important to add to the conversation that this MUTE issue happens also with midi parts. And again, totally randomly. Even doing the same routine over and over, same row manual sequence … same random issue.

Anyway I’ll go deeper into your suggestion to make sure everything is double checked. And while I wait someone else’s answer and I’m getting in touch with the support.

Thanks man!

No problem.
Regarding MIDI tracks, there could be issues of Direct Connect and/or conflicts if audio and MIDI tracks are sharing the same channel?
And of course there isn´t anything excluding that we in fact maybe are actually seeing very complex bugs showing up here.
I´ve had my issues too, that I´ve been unable to explain (see link below).

http://www.elektronauts.com/t/press-and-hold-trig-temporarily-stop-playback/3776

Since pattern (+ part settings) are interlayered, together with the possible “override” settings within the samples themselves. As well as the condition-dependant Direct Connect settings in the MIDI tracks. The Arranger may very well be “following the rules” as per pattern and tracks as well as what are set globally and determined externally with the MIDI communication going back and forth.
Which could possibly mean in the Arranger, that the settings would need to be turned ON as much as they then would need to be turned OFF, prior to the next time you want them turned ON again.

It could be logical in its own sense given how the “rules” (settings) are set. This is something that an programmer deals with daily, as they need to think about of what´s happening as well as to think about of what´s NOT happening.

But of course these conditions then aren´t optimal for anyone who normally aren´t involved in any programming. As we normally are thinking about of what (we want) happening, but may never consider to think into what (we want) NOT to happen at the same/next time.

In a way, arranging in the Arranger are in fact a sort of programming.

I hope you´ll sort it out!

There is a known (by support) problem where using per track scale and a loop on the arranger equal or shorter than the smallest track scale size, where after looping, all gets 1/16 bar late a.k.a. out of synch. Your 343’s problem remind me that.

Good luck with all the rest and keep us posted!

hey man, thanks for the additional info. unfortunately this is not our case.
we just started a brand new TEST ONLY project multiplying the same simple pattern (1 bar only) until we reach bar 342.1.1

000 a01 rep=64 of=0 len=16 bar 1.1.1
001 a01 rep=64 of=0 len=16 bar 65.1.1
002 a01 rep=64 of=0 len=16 bar 129.1.1
003 a01 rep=64 of=0 len=16 bar 193.1.1
004 a01 rep=64 of=0 len=16 bar 257.1.1
005 a01 rep=21 of=0 len=16 bar 321.1.1
006 a01 rep=0 of=0 len=16 bar 342.1.1
007 a01 rep=0 of=0 len=16 bar 343.1.2

whatever we add after bar 342.1.1, it moves the bar to the whatever x.x.2

that x.x.2 where the hell that comes from? it’s a serious bug as this affect longer arrangements and fucks up the rest of the midi chain.

we are literally GOING CRAZY.

wrote the support. desperation is what we are facing right now.

thanks guys.

testing…

cool! thanks a lot.

There is no jump here.
You need to play the arrange from the beginning?
Or the bug is noticeable even starting from arrangement row 5 for example?

I’m synching AF and Ableton Live and there are no noticeable problems after 342.1.1

it does that no matter where i start, either from the beginning, either from a different row.
so you tell me that if you add a line after 342.1.1 you won’t get 343.1.2 ?
is this what you mean?
I’m uploading a video of the test only arranger, so that you see exactly what i get.
what i wanna say, is that considering the next bar after 342.1.1, the result is that the machines slaved to my octatrack (which runs master clock and transport) will miss the first hit.
this happens again if i decide to manually jump to another bar of the arranger (after 343.1.2), will always miss the first trig on any other machine connected to the chain. which makes our performance a bit fucked up and with those unwanted jumps here and there.
the unreliability feeling rises, and i’m not sure if i want this system to be the core of my show.
this has never happened with the good old limited mpc1000.
check the video

to me that happens…i arranged a chain so i can make a row switch just to land on 343.1.1

And it shows up 343.1.2 as for pss2099.

crazy weird…and not acceptable.

hey sicijk FINALLY …

we’re not the only ones on Earth.
It doesn’t make me feel better at all, but at least if more people wake up on this maybe a solution will show up much sooner.

We have 2 octatrack with os 1.25b, and we can’t be the only ones with this issue.

Marcooooooooo…GiiiiiiigiGggiii…!!! =)

So…i’ll submit a Support Ticket…this thing should arrive to the HQ with more impact!

My hopes are that they’ll fix it before your tour!

…hopes…

Ok got it, same here, it shows x:x:2

My question is how this affect audio/synch?

…Because as far I can see, the only wrong is the position indicator, sequencer steps starts from step 1 not 2, and MIDI synch is also fine, and there is no jump on the transition.

hey man,

well it doesn’t affect the gears getting only the tempo clock with no transport. it does affect the other OT midi clock slaved (transport included, infact if i look at it, i clearly see the trig starting at the second position).

let’s say at this particular show i wanna start from a different song, who’s located later on in the arrangement (after 342.1.1). i always get this lack of play of the first hit.

i found out that if i always play an empty pattern on the first row of the arranger, i won’t get any audio “holes” in the slaved machine.

but still if i look at the counter i do see the transportation bar counter running faster than the beat after 342.1.1 (cause it actually starts counting from 343.1.2 instead of 343.1.1 … which does affect the transport, not the clock).

it’s getting very confusing i know … difficult to explain.

anyway, the elektron team is on it.

thanks a lot for spending time on this.

will keep u posted.

It does make sense, MIDI clock is one specific type (System Real Time) of MIDI messages. But Song Position Pointer (another type, System Common) derives its “position” by the ticks of the clock. However, the transport controls (also System Real Time) directly relates to the Song Position Point readout (=where to start, continue and/or stop).

FYI, I have had problem with another gear (AxeFx II ) getting messed up when getting System Common messages (Song Position Pointer) from the OT. And that one aren´t supposed to respond to Song Position Pointer at all, AFAIK. And while all are back to normal after I´ve setup an System Common filter at that MIDI port connecting to the AxeFx II, this thread surely is interesting.

Hopes it get sorted out in time.

Sorry to resurrect an old thread, but was just wondering if these issues with the Arranger were ever sorted out–my machine’s doing the same thing with the external MIDI sync getting off which sort of ruins things live. Does anyone have suggestions?

Me too. This is currently killing my arrangement, it’s a very bad bug…
Needs to be fixed asap. I have to restructure my tracklist into multiple arrangements now, which is less fun.

Any news Elektron?

Hey guys. I’m having a midi synch issue with the OT arranger too, though mine seems to start at any row past 50.

If I understand it correctly, I’m also experiencing this problem. And what it seems there is no solution for this? Arranger with MPC1000 = strange behaviour