Midi Beat Clock and OSC-Out Problem...

[Thomas Helzle]

Hey,

I currently try to synchronize Usine HH II to Bitwig Studio (BWS).

I use OSC4Bitwig (https://github.com/git-moss/OSC4Bitwig) and that works great, I have an OSC lister running in HH and already can start and stop the two in sync from BWS and song tempo is transferred (both via the Master Sync node).

But I ran into two problems:

1.) I am sending Midi Beat Clock from BWS via Loop Midi to a Usine Midi device. I found the "receive midi clock" switch and activated it in the Midi device, but this doesn't seem to do anything. I found no documentation about this, so my question is: what do I need to do so that the midi clock isn't just received but actually used?

Edit: As I found out in later tests, the Midi Beat Clock is actually received and working, the sync-drift is just so bad that I didn't notice any difference to just starting both apps by hand and set them to the same BPM.
So it looks like the sync-code in Usine doesn't do much good...
For more detail, see my findings in later posts.

2.) As I wrote above, OSC-In works great. What I was unable to do so far was sending out any OSC from Usine. I use the OSC Send node but neither Bitwig Studio nor the OSC-Monitor software I tried seem to receive anything. So again the question: what am I missing? Do I need to activate or insert anything else in my patch to make it work?
The Windows Firewall is open and allows connections for TCP and UDP for all involved software.
The OSC Monitor receives OSC from BWS just fine, so does Usine, but no tool I tried is getting anything I send from Usine.
I restarted the machine which didn't help either.

Thank you very much for any hints!

(Windows 8.1 x64, Usine HH II latest 32 Bit, Bitwig Studio 1.1.7 32 Bit)

Cheers,

Tom

[23fx23]

if i recall correctly u might have to enable 'broadcast' to send osc, also be sure ip and ports are valid in bost hosts one for listen one to receive, inverted in hosts.. maybe try 127.0.0.0 ot .1 or 192.168.1.1 as ip or chek using command and ipconfig, try to launch both as admin maybe, try single int or float as start. check back slach in adresses (don't remember if need one or not at the end)

[Thomas Helzle]

Thanks 23fx23.

I think I tried all those but the running as admin. Will try that right away (although it shouldn't be needed IMO).

The OSC Monitor software basically catches everything that is sent on the machine as long as the port is correct, and it didn't receive anything either (http://www.kasperkamperman.com/blog/osc-datamonitor/)

- Broadcast didn't change a thing here.
- I tried 127.0.0.1 since both apps run on the same machine and I also tried the actual IP.
- I use port 8000 to send from BWS and 8001 to receive.
- I tried all possible formats although it should be an int (that is what comes in).
- slash at the end didn't work either and it comes in without one from BWS, so I guess the address is without.

Since and OSC Receive node works exactly as expected with the settings I tried, I'm not sure what could be wrong with the Send...

Cheers,

Tom

[23fx23]

just an idea, ive noticed that when i download usine new installs and 'overwrite' an old folder, i can get my midi and audio io don't work as espected, but they work back again if i extract in a fresh new folder..could that be your case? could you trace out osc fine emitting from usine console?

[Thomas Helzle]

Thanks for the ideas 23fx23!

- I always extract to a new folder so that shouldn't be the problem.

- The console shows the outgoing OSC just fine, but nothing else on the system receives it.
The only thing I wondered is: the incoming, working OSC from Bitwig is shown in the console as "/play (i)" while the outgoing is shown as "/play ,i"
Not sure if that is just an inconsistent console display or if it has any significance...?

Running as admin didn't change anything BTW.

Cheers,

Tom

Edit: here is the Wiki for the OSC4Bitwig Script:
https://github.com/git-moss/OSC4Bitwig/wiki
All pretty simple and straight forward...

[Thomas Helzle]

Further tests with the Midi Beat Clock show that Usine actually DOES sync to Bitwigs Beat Clock (the song tempo changes back after a moment when I change it manually) but the sync is very unstable and drifts a lot. I somewhere read that setting the Usine Block size to smaller sizes is supposed to improve this, but even setting it to 32 doesn't change the drifting much.
Both applications show for instance 65 BPM, but seem to interpret this quite differently...

I tried different SMPTE framerates, enabled and disabled "perfect synchro" in the SMPTE settings - no joy.

I test this by
a.) playing a midi clip with 8th notes on each beat in the Bitwig Clip-Launcher and sending this to Usine via Loop Midi triggering a VST with a short attack sound in a patch.
b.) playing the same clip from a Usine Piano Roll in a second patch using the same VST.
As far as I understand it, those two should play in sync, right?

Still no joy with OSC out...

Cheers,

Tom

[23fx23]

i will try to install back bitwig and test.
when i was trying to sync live i personnaly did my own custom sync by doing so if i well remember:

setup a "master" midi clip in live that was set to my longest bar need, ie 2-4 bars. the shorter the better. that clip would send a pulse on start (was midi in live but i guess could be osc)

then in usine i used a local sync module (shoul work with gb sync as well). on that pulse receive it was forcing the restart, so both were in sync at the start of the loop.
i was using liveosc to transmit float tempo value and set localsync tempo to same value. normally drift was certainly not sample accurate^^ but fairly correct.
if i was meant to use very long sync like more that 8-16 bars, i had add a second 'tick' layer clip that send a pulse more frequently, ie each bar, and a counter in usine compared usine ticks with received from live ones ,
if the difference between the ticks is too important, this would speed/slower up a bit usine tempo relatively to timeoffset, by adding a sight offset to the input tempo , kind of auto 'nudge'. so that both kept relatively well in sync for longer period if one soft was meant to go more or less 'fast' than the other for same tempo value.

i reckon it seems not that sexy and out of the box, but in my cases that worked pretty well. i had nevr been luck with either osc or midiclock out of live/usine/hardware global perfect sync.
mind ya that was 2-3 years ago. im pretty sure there is a more efficient and easy manner now. will try to give a shot didn't try osc in bitwig yet

[Thomas Helzle]

Interesting. Thanks again!

I tired your master clip but that gives me a kind of hickup since the offset per bar is already quite a lot, even with both apps set to the same BPM.

I set the engine to "on" via OSC from Bitwig ("/play") and global sync - this works quite well. I disabled the OSC transfer of the tempo since the Beat Clock does this (and probably should).
Your idea to nudge this via a counter and some fast notes sounds brilliant - I'll have to try this tomorrow.

OSC from Bitwig is done via it's scripting API which isn't made for time-critical stuff. The Midi Beat Clock on the other hand is sent from the audio engine directly and should be tight.

It's funny: Both apps run on the same machine, everything uses 128 sample buffers (Asio, BWS, Usine), both use the same ASIO audio and still 65 BPM comes out differently

Cheers,

Tom

[Thomas Helzle]

Did another test:
Same setup, Bitwig Studio as Master, but this time Ableton Live as Sync Slave.
Same thing about the midi clips using the same virtual Midi driver.
Result:
Very very good sync. May not be sample accurate but it is perfectly usable.

So it looks as if the external sync in Usine isn't working correctly.
Maybe I should report this as a bug/problem then?

As for OSC: is anybody able to send OSC out from HH II?

Cheers,

Tom

[ahonoe]

Hey Tom,

Did you enable "receive MIDI clock" on the MIDI input device?

[Thomas Helzle]

Hey ahonoe
As I said in my first post, yes I did enable "receive Midi clock" and yes, it kind of works, but the sync is so bad that I didn't realized at first that it is actually "working". I get the same massive drifting as if I just set both apps to the same song tempo and start both manually.
So the problem no longer is that it isn't working, but that what it does is pretty much useless compared to for instance Ableton Live (see the post above yours).

Cheers,

Tom

[23fx23]

i just quick gave a shot to the "manual patch technique i mentionned i used to do by the past. with only midi , ableton & usine.
you can see the audio result in this vid, while not perfect it's quite correct imo.

https://drive.google.com/file/d/0B0VUyz ... sp=sharing

maybe could be used as a workaround for now..
no time midi time clock neither smpte was used, only goold old mid^^ a restart tick each 4 bar clip , that i think could go up to 8 16 ,32. and a each 16th much finer resolution clip for the drift tracking & auto-nudge compensation
did a simpler setup than i did by the past but it had descent reults while being 'relatively' simple i find, maybe not sample accurate, but better than ie when i try to midi sync hardware like an electibe with live with classsical midi clock.

here is a pic of the setup if wanna try. basically one clip emmit from live a pulse each 4 bar. at start usine filters channel 1 and note on mess only and use as restart.
a second clip emits a much finer resolution, here eah 16th and emmit on midi ch2. usine filters this ch and note one as well . then we compare the pulse from receive & usine master sync to obseve the latency/jitter (you do see it well with oscilloscope. while tweaking, after fine adjust the re is quasi no jitter. then just adjusted the offset in live to compensate buffer, midi & overall latency so that 'dummy' midi clips actually trig a bit before the "should be in sync" stuff that we herar, here basic metronome midi operator used as a test. if no offset avaible in other software man could manually offste notes then just add a multiplier fader to observed jitter so that it will be invert returned result & fed back as a nudge to tempo.
This normally should work with any software, that is midi capable, and provide a while not perfect descent sync. hope it can help

[Thomas Helzle]

Interesting - I'll check it out today. Thanks!

I wrote a support ticket about the sync problem since I think it would be good if it would be working right out of the box as good as when I sync Live to BWS.
Something like your setup should be possible to build into the internal HH sync code directly, using the beat clock pulses instead of Midi notes.

No luck with OSC-Out still.

Cheers,

Tom

[ceasless]

Re: OSC out. Just a thought, but have you checked your firewall settings? Is Hollyhock allowed to open ports?

[Thomas Helzle]

Yes, all the involved applications are explicitly open in the Firewall.
OSC works on my system with every other app I try and input works as well in HH.
Are you able to send OSC?

Cheers,

Tom

[Thomas Helzle]

23fx23: I tried the setup but for me it doesn't get stable.
For now I have to tend to other things, spent too long on it already - hopefully Senso can fix this at the core so that Beat Clock works better without tinkering.

No idea what else to try with OSC either.

Cheers and thanks for all the help!

Tom

[nay-seven]

As for OSC: is anybody able to send OSC out from HH II?

yes, of course, no issue here, broadcast mode or to another machine ?
try to create a simple patch: a send OSC and a lfo on data inlet, osc lister on the other machine/application ( i test with reaktor in broadcast mode)

[Thomas Helzle]

Good to know that it works for you at least.
I used an even simpler patch, a switch sending 1 or 0... No joy.

I have to give up for now but will try again when time allows.

Thanks and cheers,

Tom

[Thomas Helzle]

Update:
Senso answered my ticket from yesterday about the Midi Beat Clock issue and said he has release .68 working perfectly in sync with other hosts!
Brilliant, that should make it much easier for people to integrate HH into their setup without complicated workarounds

Thanks a ton,

Cheers,

Tom

[ceasless]

o/

[Thomas Helzle]

Oh, and I just solved my OSC out problem - It consisted of two things:
a.) The OSC4Bitwig script has a bug when you set the receive port in the GUI, it doesn't actually use that port, you need to change it in the script itself. I'll report that to Moss, the author of the script.
b.) Port 8001 which I was using for listening to Usine is somehow used already on my system (I don't know by what). Going to 8002 solved that part.
Thanks for the hint about using Reaktor as OSC testing tool Nay-Seven. The other OSC monitor I used somehow didn't hint on 8001 being taken already.

So: all problems solved and fully synced interaction with Bitwig Studio should soon be possible.

Yay

Thanks a lot for all the help!

Cheers,

Tom

[nay-seven]

Good news !
and about the port number, yes, that something we have clarify with senso cause in the setup it's the OSC receiving port ( and this will be renamed in the setup in next version)
so you can use 8000 in receiving port but you must use a different one to send OSC datas

[Thomas Helzle]

Hey Nay-Seven,

that was not my problem, it was the port settings in the OSC4Bitwig script that didn't work correctly. I understood the Usine part.
I am using port 8000 to receive in Usine (in preferences) and (now) 8002 to send. I didn't investigate what port 8001 is occupied with

And yes, good news indeed

Cheers,

Tom

[Trench i/o]

Hi,
I'm struggling with the same setup, well almost the same. I have Bitwig on Linux and it sends midi clock to Usine which is on OsX and the midi clock is very stable but unfortunately a bit off in Usine. What I mean is that when having metronome on in both softwares the Usine is a little behind, it sounds like it's the same amount no matter what the tempo is in the master. What I would need is a simple offset function in Usine, I have a Max sequencer which has that and it works great... Any tips?

Thanks,

J.

[23fx23]

maybe the simple manner would be to add a precise delay (in sample number) to audio coming out of bitwig master. it's probably around one bloc latency y guess

[Trench i/o]

Thanks for your comment. The bigger the buffer the better timing tho' I should add. I have 4 stereo outputs and one click track so I would then need add delay plugin to all of them since there is no track offset in bitwig. I might try that still...

Best,

J.