Best,
J.
Statistics: Posted by Trench i/o — 29 Aug 2015, 00:01
]]>
]]>
Thanks,
J.
Statistics: Posted by Trench i/o — 28 Aug 2015, 19:07
]]>
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
Statistics: Posted by Thomas Helzle — 23 Apr 2015, 18:13
]]>
so you can use 8000 in receiving port but you must use a different one to send OSC datas
Statistics: Posted by nay-seven — 23 Apr 2015, 18:08
]]>
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
Statistics: Posted by Thomas Helzle — 23 Apr 2015, 17:19
]]>
]]>
Brilliant, that should make it much easier for people to integrate HH into their setup without complicated workarounds
Thanks a ton,
Cheers,
Tom
Statistics: Posted by Thomas Helzle — 23 Apr 2015, 15:25
]]>
I have to give up for now but will try again when time allows.
Thanks and cheers,
Tom
Statistics: Posted by Thomas Helzle — 22 Apr 2015, 18:02
]]>
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)
Statistics: Posted by nay-seven — 22 Apr 2015, 17:55
]]>
No idea what else to try with OSC either.
Cheers and thanks for all the help!
Tom
Statistics: Posted by Thomas Helzle — 22 Apr 2015, 17:46
]]>
Are you able to send OSC?
Cheers,
Tom
Statistics: Posted by Thomas Helzle — 22 Apr 2015, 16:59
]]>
]]>
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
Statistics: Posted by Thomas Helzle — 22 Apr 2015, 16:43
]]>
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
Statistics: Posted by 23fx23 — 22 Apr 2015, 14:11
]]>
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
Statistics: Posted by Thomas Helzle — 22 Apr 2015, 12:11
]]>
Did you enable "receive MIDI clock" on the MIDI input device?
Statistics: Posted by ahonoe — 22 Apr 2015, 03:28
]]>
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
Statistics: Posted by Thomas Helzle — 22 Apr 2015, 00:59
]]>
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
Statistics: Posted by Thomas Helzle — 22 Apr 2015, 00:48
]]>
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
Statistics: Posted by 23fx23 — 22 Apr 2015, 00:16
]]>
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
Statistics: Posted by Thomas Helzle — 21 Apr 2015, 23:56
]]>
- 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...
Statistics: Posted by Thomas Helzle — 21 Apr 2015, 22:32
]]>
]]>
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
Statistics: Posted by Thomas Helzle — 21 Apr 2015, 22:11
]]>
]]>