Midi tracks refused tp play, needed reboot

Hi,

I messed around with midi tracks today, very simple stuff, just enterering some notes in grid recording mode, then got the usual WTF hour to get them them to play. I finally rebooted the OT and they worked right away.

What could I have done wrong? (90%, if not more, chance I did, of course)

Thanks!

Did you pray before play? :content:

2 Likes

Was there incoming midi, too? I’m thinking in the line of a stray solo/mute CC …

1 Like

Good question, but I don’t think so, I’ll check again (there’s quite some routing going on on the midi side of my rig) but I don’t use incoming midi for the OT except for my footcontroller which is only configured for the crossfader and pick-up machines. Alle the play commands just seemed stuck, all midi tracks were affected, I couldn’t get any to play, not even in play free mode.

Yes good question. I think once or 2 I had things stuck because of too much midi data, with midi loopback.

I will go through the whole midi routing tomorrow in the iCM4+. Could be a midi loop too. I have spend weeks on the midi routing/filtering to get the most out of the set-up and I have been very careful but something might have been overlooked.

Happened again today. I checked the midi routing, there’s no midi loop. I’m puzzled…

This ones weird man… I’ve never had the OT even stutter yet alone stop performing a function, except things I tracked down to user error of course…

I had a few ideas but none of them would make sense to work after power cycle…
Stumped… Hope it’s not hardware related, maybe send a support ticket see if the Mothership has heard of anything like this happening…

1 Like

Same project? A lot of data out, like continuous lfos?
I’d try with a new project with same conditions.
I’d also try with midi in disconnected or a midi monitor before to be 100% sure.
I hope you’ll find out.

The problem with this type of annoyances is that it just happens every once in a while, so if it’s once a day in a 10 hour session (that’s my daily routine) it’s very hard to link to a particular event. I’d rather not yet disconnect anything because I have quite a good remembrance of what I was doing today when this happened, and I hope this will occur again tomorrow so I maybe I can discern a pattern then. (A behavioural pattern , I mean of course). I am sure nothing is being routed to the OT in the iCM4+ routing except my MFC10 footcontroller that was not used. (And the MFC10 is out-only in my set-up, so no midi loop possible).

Although not often I have had similar issues happen with my octatrack as well. Patterns that play perfectly fine all of a sudden just stoped playing until I rebooted. it took me a couple times before I realized that I sent some of my stuff to cue outputs but after I figured that out, it still happened a few times. all my tracks just mute themselves I’ve never had issues with midi though…

That’s a good point.
How are you monitoring? Back though OT or purely outboard? Could it possibly be tracks are going but not being monitored?
Can you see the sequencer progression lights moving at all on the midi tracks or nothing?
Are you pressing the main play button or track+play?

Monitoring by outboard mixer. The sequencer runs but no midi trigs are played (the little “stopped” square doesn’t change to the “playing” arrow). Main play button starts the sequencer ( running lights, audio plays). Track+play doesn’t start the midi track. Yestrday I had one midi track running OK and 3 we’re faulty. So it isn’t an global midi sequencer issue.

Did you use Play Free tracks and part changes?

2 Likes

I was changing parts. I saved part 1 (that was in a OK state), then switched to part 2, then back to part 1 again, and so forth. I tried reload part to no avail. (All in the same pattern)

And this morning, I wanted to record a bass part using a PU machine and it just didn’t want to record more than 128 steps. Lost one more hour trying to figure out why, then I had the “reboot reflex” and bingo! it worked again, with the exact same settings Basically everything I try to undertake these days fails to work properly and needs rebooting at one point. For someone who is still in learning stage this is very stressfull, I must admit. Just when I say to myself OK, you master this part, I validate its integration in the live set, it stops working.

Now there’s one thing that might influence this: I’m working my ass off for my new project, getting up very early and finishing very late , and I leave the equipment powered on at night. The unit does’t seem to overheat though. I hope it isn’t hardware related like some heat problem: these days my house is at 18°C but I live in the Mediterranean region, and in summer it gets really really hot here, I don’t have airco and I do outdoor gigs.

I experience two types of ’wtf’ moments after 2y with OT:
-after user error
-after part change

Just five mins ago: recording with one shots after part change is completely messed up. Also src3 needs to be reselected sometimes. Part reload helps partially.

1 Like

After some thoughs, you might have put me on the right track. I had switched the offending track to “plays free”, and then back to normal again. It might be that the switch back to normal wasn’t registered until I rebooted. I’ll try to reproduce this. Could be a bug, or some key-combination I ignore (probably the latter, but there’s no “freeze until reboot” option, is there?..)

3 Likes

Beware of Part changes. Especially if you want to change Rec Setups, sometimes changes are not effective at all. You need trigs to make changes effective so Pickucks (no trigs) are problematic too.

I avoid Parts change, I use them only under torture…:smile:
I don’t use them for a simple track default sample change.

I can’t get “plays free” to work on a midi track. Is that normal behavior? We are given the option, so it should work…

EDIT I can get them to play by triggering them in track mode, in which case they start quantized but not by track+play