Spigot~…I’m not sure if this question belongs to the jitter or msp forum. I am using mac 10.5.8, max/msp/jitter version 5.1.5 and quicktime 7.6.6. When I read a video into the spigot~ help file, (or any patch with spigot~) there is a long delay before the sound begins.
On my macbook pro, I can open the same video and there will not be a delay the next time.
On my mac mini, also 10.5.8, the delay happens even after the same video has previously played and an xml file is created. I would be happy if the mac mini worked the same way as the macbook pro and the delay could be prevented by opening each video once. Both computers are playing the same set of videos but on the mac mini I am opening the patch in runtime, not max. Also both computers have the same version of quicktime, but the macbook has quicktime pro and the mini only has quicktime player.
Any help would be greatly appreciated. Thanks.
spigot~ has been a problem ever since the release of Max5. it doesn’t seem possible for the cycling devs to improve it due to the dependence on changes in quicktime 7:
"Under QuickTime 7, spigot~ no longer works via a Sound Ouput Component, due to changes in the QuickTime architecture. Instead, a sound file is exported from the loaded movie, cached, and played in sync."
Exporting and caching is not the nicest, quickest way to handle synced audio.
People have been running into similar problems with spigot~ for about 2-3 years now.
(But you did pick the right forums, spigot~ is part of Jitter…)
I don’t know if this will help at all and what your disk setup is, or if you have already tried it… but you can change the location of the cache for spigot (you may already realise the xml file is not the actual audio file). Look in the spigot help file and it will tell you how to store the audio file in the same directory as the movie, the default store is ~/Library/Application Support/Cycling ’74/spigot-cache/. For this reason, if you have two patches using the same spigot name they will need to recreate the audio file again if one has been opened since the other last was if that makes sense.
I’m on MBP with QTPro and have the same experience as you, the first time it takes a while, but then it is fine every time after.
@scatalogic: In my patch the user can choose out of 5 films. Is the cache always filled with the last film played or are all films stored? I could play the films before the exhibition opens so that everything is cached. Do you have some patch where you can demonstrate the spigots behaviour?
If the 5 movies all go through the same jit.qt.movie object which has one spigot/soc name, then each time you load a new movie it will have to cache a new audio file. i.e The cached file will be overwritten each time a different movie is loaded if the soc/spigot name is the same. This sounds exactly like your problem, so…
Three options I can think of right now:
1. Have more than one qt.movie object, each with its own spigot
2. Auto select between different soc/spigots each time a new movie is loaded, one for each (might be dodgy)
3. There’s a nice example of using poly~ for movies which you may be able to wrangle here: Max5/examples/jitter-examples/video/quicktime/PolyMovie/Poly~ForMovies.maxpat
If you need to switch between movies quickly then I suspect the poly method will be best if you can get it going with spigot.
I am experiencing this problem at the moment. Has there been a solution since 6 years?
I am developing a ‘video keyboard’ that reads short movie files from a folder. It is essential that the audio starts immediately when triggered. The above described delay in spigot~ is therefore a big problem.
Any help appreciated!
jit.movie~ is the solution.
Forums > Jitter