MarOS1.4.1 - "Official" Version 1.4.1 - IMPORTANT bugfix

[rarara]

Not sure, I found the half tempo behave right (end of pattern change), so changed nothing. Did you say its a specific mode that it doesnt work in?

yes, its in 'user a' (but didn't test it in any other mode)

[mario1089]

That mode is very very rough. Found it deactivated in sokkOS2.0. Code looked like not worked out at all. Don`t think Ill fix it. To have MIDI sync while editing, start playing in MIDI Sync mode, then go to editing without stopping. Not sure, but I think that`s the "official" way to have MIDI sync while editing. But I don`t think switching to half tempo while editing is implemented properly at all (but being in half tempp mode is fine, just the switching is a bit messy). I`d say that only works well in normal play modes. And I think that should be ok, isn`t it.

[pangrus]

In SYNC OUT mode everything's perfect.
Machines syncs perfectly, and swing together, also in triplet mode or half tempo.
Nothing more to do on the sync side, up to me.
When you save you mess up the clock, but I've checked and this was also the case in Sokkos 2.0.

In MIDI SYNC, I still get the clock disallignement.
I attach a wav file where I just start-stop the machines, see the results...the xox is always earlier, sometimes by little.
The fourth start-stop is where the problem is more evident.

Midi sync test _95 bpm.rar

(648.68 KiB) Downloaded 48 times

Hope this will help.

[mario1089]

Good idea, thanx for the file.

So that`s an electribe as master, then the xoxbox in MIDI mode, then a 303 on xoxbox output right?

If that`s the case, the question is: Is the box playing too early (MIDI Sync In -> playing not right), or is the 303 too late (playing -> DIN Sync out not right).
To test this, you need to compare against the electribe audio out. Can you do so?

Looking at the file, we see the box is early 2 ms (except for the "bad" try) - I won`t be able to fix this, the new system is more involving CPU processing introducing some delay that`s always there:( The old system was straighter. How bad is that? I personnally think it`s ok, given the fact the MIDI system have bigger latencys, and also when producing I found that 1ms is always ok, 5 ms is the edge of thinks being not always ok, so we`re in some okish area..

[pangrus]

Ok, here we are!
In the attachment, the files with electribe,303 and xox.
BPM is 120, programmed notes are 1/8

test 1.4 beta5.rar

test files

(647.59 KiB) Downloaded 39 times

There are a lot of considerations to be done.
In the stereo file, you get bass drum and clap at opposite pan. Korg delay it by some ms...is intentional or accidental?
As you said, when the sync works, the delay is present but accettable, 2ms are good, and I hope nobody is programming this kind of test boring patterns.
When it fails....ok it fails!
At this point, some other testers are needed, to confirm or deny my results.
Now I go to play, I'll revert the xox as master

[mario1089]

The failing will be fixed. I hope. The normal 2ms won`t, but as said - acceptable - and I am a producer and not just a tech nerd:)

If kick and clap are off time (to each other) a little, it`s surely not the box`fault. Could be they found claps to make sense that way, or their sample guy had a bad day:)

[mario1089]

Looking at the files (very good, thanx!) I`d say the korg itself is a little late processing its own events, while the box seems to react more sudden, so it`s not our fault. I`m almost sure, as the offset is 1) not random but constant, and 2) small. that accounts for a systematic problem and not problem in the logic of processing.

Then the late 303 is the box sending late clocks, or better bad timing of start signal and clock signal. 303 is late 22 ms, that excatly one clock at 120bpm. Need to fix that.

[pangrus]

Yes, you're right.
Its obvious that the electribe first starts to generate the clock and then starts to play...as you said, the samples are not well triggered or the machine is a little sloppy (or funky ).
So it's not a problem of your firmware.
Note also the 303 first note lenght...weird.
Hope for a new release soon, is a pleasure to help.
cheers

[mario1089]

Ahh, thanx for pointing me the note length!! We can see the 303 starts correctly, but then seems to miss one of the next clocks (I`d bet the second), so that makes the first step longer and then anything else late one pulse. Super Helpful to know this!!!!

[mario1089]

I did some investigations last night, but it turned out that the last version I posted is all I can do for you regarding the issue(s) reported.

It works all fine when the box is master for your DinSync gear. You can slave the box perfectly to MIDI clock. But when doing both at the same time there seems to be an issue, that not all is reliably in sync every time -although my tests show there is nothing generally wrong. So, we have to live with that. I doubt that the issue as reported is consistent for different setups, I think it`s a bit random how good it all works.

Nevertheless, attached is a new beta with 2 changes:

1) I copied Osmk411`s hack to have better MIDI sync synchronicity: In parameter adjustment mode press A#-KEY to turn on/off the hack. The state is stored on the eeprom, so kept until you change it again, even if the machine is turned off. It adds an additional Sync Pulse (both for the box itself and for the DinSync output) whenever a MIDI-Start command is recieved. This helps for syncing to setups that send the MIDI-Start and the first clock almost at the same time. In that case all firmwares (adafruit, sokkOS) are missing the first clock. With certain environments this is a great help to use the MIDI Sync mode.

2) I improved the internal tempo measuring used to calculate the distance of the clock/Din pulses while slaved, so that it is a bit smarter/safer.. This will reduce timing jitters both for the box and for the sync outputs - not sure if audibly or only measurably.

So, if nothing serious is coming up from you during the next days, this version will be the last, "official" (whatever that means) MarOS. Please do some tests!

Thanx,
Mario

[antto]

according to midi specs, when a MIDI_START is received, the sequencer shouldn't start, but only "prepare"
the actual start is on the very next MIDI_CLOCK message
sadly the x0x starts immediately on the MIDI_START message, and when it's master - it sends MIDI_START and also starts immediately

i also discovered some new bugs, it's too late to fix them in the stock firmware because no one uses it, everyone uses the custom ones (this one, sokkos..) and in both cases, there is no free space to apply bugfixes
but i will do it for the cpu mod firmware (and help is appreciated) .. it's important to have a "proper" firmware as a foundation

[mario1089]

according to midi specs, when a MIDI_START is received, the sequencer shouldn't start, but only "prepare"
the actual start is on the very next MIDI_CLOCK message
sadly the x0x starts immediately on the MIDI_START message, and when it's master - it sends MIDI_START and also starts immediately

Not sure if I agree:) Actually the xox - as I think - is kinda gentle: Waits 5ms to send the next clock after MIDI start. But this is where the trouble starts. Firstly any midi synced playback is 5ms late (the firmware that I privately work with has all of this things #MACRO-ed-out, and I can see the box now being tight). Secondly it seems any clock from outside is ignored during that time. Here it gets difficult. You can`t just change things to make the outa world happy, as any change also changes the internal playback. So if you want to have a perfect sync firmware, I think, there`s a need to seperate sync-conversions from playback. Or be very very smart:)

[antto]

try it, send a MIDI_START (without any MIDI_CLOCK messages at all) and the x0x will start playing
it's not hard to fix this bug
in any case the x0x deals with the dinsync signal (doesn't matter if it generates it or if it comes from outside, or if it converts it from midisync)
MIDI_START would translate to raising the dinsync RUN signal up, and clearning the memory of the CLOCK counter, so that the very next MIDI_CLOCK results in clock tick 0 and THAT's where the x0x should start playing

actually, it might be a good idea to force the CLOCK to go down on MIDI_START, so that it *really* does retrigger

[mario1089]

try it, send a MIDI_START (without any MIDI_CLOCK messages at all) and the x0x will start playing
it's not hard to fix this bug
in any case the x0x deals with the dinsync signal (doesn't matter if it generates it or if it comes from outside, or if it converts it from midisync)
MIDI_START would translate to raising the dinsync RUN signal up, and clearning the memory of the CLOCK counter, so that the very next MIDI_CLOCK results in clock tick 0 and THAT's where the x0x should start playing

actually, it might be a good idea to force the CLOCK to go down on MIDI_START, so that it *really* does retrigger

I can`t exactly see your points. My xoxbox does not start when there is no MIDI clocks. Not at all, I checked. Furthermore, while stopped both DInSync signals are "silent", low. No need to put to low on start therefore. The only things of interest for me are: 1) why does the xox not "see" a MIDI clock if it happens to arrive right after the start signal? 2) Why is pangrus 303 sometimes later than the xox, while actaully all signals look good and are pretty much conected to the box playing??

[antto]

the dinsync clock should always be ticking.. otherwise slaved machines won't "blink" ... (the x0x cheats via using a timer to blink when there is no clock)
i am talking about the stock firmware
i can't test the thing easily since i only have a x0x and a PC and no other "gear" ..