VIDVOX Forums ~ View topic

i'm trying to get clips to loop reliably to a locked bpm in either vdmx or grid pro. posting under gp as thats the saner of the two apps for anybody trying to do this - its supported for starters!

this is important as its the fundamental building block of any kind of 'see the dog / hear the dog' musical performance - ie pretty much what everybody i've seen wants av-wise (tho only a part of what i'm doing with rbn_esc___av)

--- strategy one is to play the clips at a rate that is perfect for the length of that clip over the number of bars it rhythmically corresponds to. this is ideal as you have video playing at a nice smooth rate - good for the computer load and codecs etc - and you get nice smooth sound. if it drifts, it could be corrected with a simple restart the clip on a looping pulse, thats easy.

strategy one failed - this needs to be built in, it can't be hacked on, i might be able to assign speeds by trial and error for my show but it would take years and locks down the dynamics of the show.

--- strategy two is to drive the playback head with a sawtooth oscillator set to the appropriate number of bars. this will probably destroy the audio, and it can't be efficient commanding the playback frame-by-frame. the audio can be moved out of the vj app and into ableton live, which is probably for the best anyway.

strategy two failed - the midi clock signal seems to be unreliable over multiple bars. i haven't tried with a hardware clock source, but using ablteon live with either vdmx or gp i can't sync anything over a bar reliably. the midi clock of the vv app seems to think the bpm has changed and restarts, with the result that any slider sync'd to say 2,4 or 8 bars will likely restart itself over that period. i don't know whether its ableton giving out a slightly erratic signal or vdmx and gp both falling out of time with theirselves, but i have tried the basic setup with no music/visuals load both on a separate machine and the same machine... so its a fundamental problem, not things falling apart under 100% cpu load.

--- strategy three is to drive the playback head via midi data coming from the external sequencer. this has the same flaws as two, but now as the frame-by-frame control is coming from outside vdmx/gp, theres even more potential for stutter.

strategy three failed - midi continuous controllers have a poor resolution of 0-127, which isn't smooth enough to drive a playback head along a timeline. there is the pitch bend controller, which has a much higher resolution, but whenever i send this volume of midi data into vdmx it crashes within minutes if not seconds. i haven't tried it with gp, so there is hope, but for me right now gp currently won't do some other tricks i need which i have hacked into vdmx.

anybody had any better luck? ideas? and vjamm is not an option!

toby

hey toby, I'm investigating similar ideas myself...

don't know for sure but this might help..

what about driving both ableton and grid pro from a single midi clock but an external software one?

eg

http://www.grantedsw.com/midiclock/

see if that helps...

but absolutely strategy 1 needs to be supported automatically in grid pro for av sets, I'm sure they can add it but maybe not in time for your current project?????

I've actually been talking to Toby about this directly, but I wanted to chime in my comments to the forums post for good measure. I think the best strategy of the 3 that Toby listed is the third, using a pitch-bend out from Live to drive the movie position in GP. 14-bit MIDI would be accurate for a movie up to 10.92 minutes (@ 25fps) and all the sliders in GP are designed to receive 14-bit.

For strategy 1.. this is actually something we tried out for Grid2, there were some early beta's that had a 'time stretch' feature. Unfortunately we just couldn't get it accurate enough at the time so it was scrapped and replaced by the Retrigger option. Just opening a movie in Quicktime player and watching the Playing FPS, there is some slight variation during playback. I'd venture to guess that Live isn't using Quicktime for it's playback (the only mention I see of QT in their manual is for being needed to decode variable bit-rate audio). Video happens to be more forgiving than audio since the timing resolution is 33 or 42 ms, if a frame is off by 1 or 2 ms your eye doesn't usually notice. And as for strategy 2, MIDI BPM sync has always been pretty unreliable for us, but perhaps there's something to be done for the 1.1 update to ignore slight variations and prevent the restarting of the clock.

Anyway, I'm working with Toby on getting the most out of slaving GP to Live which will no doubt lead to some small improvements for GP (like added MIDI trigger support to the s.tap-movie FX), once everything is sorted out I'll put together some wiki pages with some of the techniques.

- Dave

I'm anxiously awaiting your results but if midi clock bpm sync is unreliable then suspect it may be your implementation that needs reworking...

your shouldn't need to restart the midi clock when the bpm changes, you just change the timing between beats on the fly and adjust the measure timing.... adjust it in mid bar....

this is how I've got it rigged up in my quartz composer patches and it's reliable and good....

Hi Toby,

One other application to try is Numerology, I use it behind GP and it has only a hit of around 0-4% on the processor. Its basically a fully modular midi sequencing program and has some really nice features, one that I am working out that is a pitch bend sweep module. In performance I have had no problems running and switiching between the two apps. Jim who makes the program is very responsive ala vidvox crew and will help with questions that will arise.

http://www.five12.com/

Other applications for Num are using video / audio anylsis from GP to drive sequences. Num also has some nice range limiting features, eg compressing signals down from 0-127 to 45-55 etc great for controling audio analysis and then feeding them back into GP.

On midi sync I also use a Redsound bet detector and the bpm sync is not to bad, but there are issues with wave playback. That said, I would like to see an overal of the sync at some point - after GPU though.

Cheers
Keith

have to say I disagree with that priority vib

rock solid sync issues for avsets should be number 1 priority for grid pro... this is a potentially huge market for vidvox, there is no other product that can do it other than VJamm Pro which is expensive and pc only....

Grid Pro's strength is exactly in it's timing control, powerful sliders and clip speed retiming. it has no peer there...

but that's all useless if it can't accurately lock up and maintain time with other programs...

this is far more important than gpu fx in my book, fix the bugs before adding new features...

Fair call, however the midi sync I get from decks through a redsound is pretty solid - ablit the major bug that sits in the sliders when set to be slower than 2 bars.

What I would like to do though is to be able to control playback speed alot more by have a far cleaner and faster output. When you see a Quartz vj app mixing 640x480 pal dv files off a laptop hardrive with really smooth and clean playback I just have to look at the slight stutter on my playback and grown. So many times I want to be able to cut the frame rate and the send it straight up in line with the tone of the audio, that though isn't always obvious because GP never seems to let the play back just fly.

i'd agree with av level sync being the priority before all others - my vision of grid pro (and we're talking way back, following the ditched the polyphonic prohpet successor) was the same grid premise (no effects, barely an interface, total timeline control) but with two or three layer polyphony and reliable 640x480 playback. but anyway, a few complete rewrites later it all looks quite different, in fact its effectively a vdmx reinterpretation which is no bad thing. anyway, i digress.

yes, vv have been doing their best and a new build that is ableton (and spark-av) friendly should be on its way. i've got two main conclusions at the moment -

1 - we as a community need to develop some form of API/interface for integrating visuals programs with ableton. its not such a nuts idea, and its good for everybody. i have an idea of what functionality would be needed.

2 - palming the audio of looping clips to ableton and driving the vj clips timeline directly from ableton via continuous controllers is the way forward at the moment. it works (with a few footnotes), and it works from a workflow perspective. interestingly, this is how coldcut do their av shows, even if vjamm is audio sample tight.

keith -
> ablit the major bug that sits in the sliders when set to be slower than 2 bars.
that isn't a bug with the slider, its the midi clock resetting itself. and i already have ableton doing all the sequencing... just midiclock is a flawed per se, along with 7-bit controllers and much else!

toby

oh - and i promise a full write-up of how i did it all, for the love of the vj scene =]

toby

thats still a bodge. it details of implementation can still use existing protocols, i'm talking something much more useful, ie vj app sends the audio of its vj clip library to ableton type stuff. anyway, off to newcastle for me right this second...

toby

OSC can send any arbitary data between applications., including binary data that could be sound files.. I'd be very surprised if it couldn't do what you want.

it already exists and it's out there, the fact that it's already in MAX/MSP means it's very easy to add to all the existing MAX/MSP based vj tools.

You have a much better chance of getting widespread adoption by using something that already exists and has some momentum already.

ok doing some research, what you want toby can almost definitely done by a combination of "ReWire" and "OSC".

ReWire sends audio back and forth, already supported by Live, Max/MSP and Arkaos.

maybe it can be done already with Midi + rewire.....

like to hear exactly what you have in mind after yer gig

http://www.propellerheads.se/technologies/rewire/index.cfm?fuseaction=mainframe

As a note, there's already some Rewire support built into Grid2 for clock syncing, and it'll be in GP at some point as well.

OSC is something that's come up in discussions in the past and it's something we'd like to add support for down the road. The general consensus here is that it's not a priority at the moment (not like improving MIDI clock). OSC is still in it's infancy and while it is supported by a handful of applications, the fact that it can send arbitrary information and the lack of standard protocols for what information is being passed around and how it is formated means there are lots of possibilities for how it can be used within a single application (sounds like a great way to access shortcuts in GP), but also a lot of work dealing with potentially proprietary protocols from other software/hardware that send off OSC. In other words, it's important to have a well thought out implementation and there are more pressing things to work on at the moment.

That said, I think OSC is pretty great.. MIDI was good for it's time but it's over 20 years old at this point. Not to say that there isn't still room for innovation with MIDI, but last year one inventors of MIDI said in an interview that he was surprised that there haven't been any significant changes/improvements to the MIDI spec (there are two unused pins on MIDI cables that were intended to leave room for improvement and backwards compatibility). Then again, considering that we are still using the same video broadcast standards as set by the FCC in the 1950's.. that's enough of a rant, back to work.

- Dave

ok, now that i have my iMac running Logic, and want my music track to drive GP running on my G5 Powermac, i am forced to finally have to face the angst of making them talk through midi.

i have been reading this post (and others) trying to understand it hoping it helps me figure it out. but so far i seem not to find a simple answer and the manual lacks info on midi input. or maybe i'm just too stupid to understand

i'd coud sure use any pointers from those with more skills using midi...

1- do my macs have to be physically hooked up via a midi cabel or will a wireless network connection work. that leads to the second question

2- if no cable required, then what do i need to turn on to make them communicate? and, the reason i am asking,

3- i would like to use the BPM (midi tempo track) from my song (iMac) to set the BPM in GP running on G5. i have logic set to send midi, but do not know what to do next. the settings i would expect to find seem to be missing or appear as another word i don't understand.