Repository navigation
.cue() cannot be called very quickly in 2.2.2. It works as intended in 2.2.1, however. #40
Description
Activity
Thanks for reporting!
Hmm not entirely sure why this is happening. Does your code rely on other calls to
.isPlaying()? The only relevant change from 2.2.1 to 2.2.2 was thatisPlaying()should actually work more reliably now than before, so maybe your code relied on some unintended earlier quirk of the Sound library code.If every one of your calls to
.cue(time)is followed by a call to.play(), could you try replacing all those double-calls with a single call to.jump(time)? Does that restore the intended behaviour? (this should work with both version 2.2.1 and 2.2.2)If it also doesn't work using
jump(), could you post the complete outline of your sketch here (minus the animation code), then I can debug further.Many thanks!
Not a prob.
Does your code rely on other calls to
.isPlaying()?.isPlaying()was only used when.cue()would not work insetup(), so no.If every one of your calls to
.cue(time)is followed by a call to.play(), could you try replacing all those double-calls with a single call to.jump(time)?I actually forgot to mention that
.jump()did not seem to be working properly either! I was more familiar with '.cue()', so I didn't experiment much with '.jump()', but I did replace the two calls, as you describe, and if I recall correctly, it acted the same or very similarly, with silence followed by occasional sound.Here's the relevant code, minus the animation stuff:
setup() { . . . path = sketchPath(song); in = new SoundFile(this, path); fft = new FFT(this, bands); spectrum = new float[bands]; fft.input(in); frmrate = 30.0; } void draw() { frameCue = frameCount/frmrate; in.cue(frameCue); in.play(); fft.analyze(spectrum); (pseudocode): loop through number of _bands_ as _index_ { assign value from each band in spectrum to an array for the animation like: value = _index_, adjusted to be displayed logarithmically amp = spectrum[value] array[index] = amp } animation stuff using the amp values stored in the array . . .@bpeterson37 sorry it took a while longer but I think I've got it sussed out, could you do me a favour and try installing the following sound library test build to see if it fixes your issue? https://github.com/processing/processing-sound/releases/download/v2.2.3/sound.zip
Just extract the zip file into yourProcessing/libraries/folder, replacing the content of the existingsound/folder.I also fixed a small issue with
jump()which should now have the exact same effect as callingcue()andplay()directly after each other, so you should be able to use those interchangeably.Hey, sorry for stepping in but:
I had a similar issue with 2.2.2, but in a variation:
I couldn't call.stop()and.play()right after each other. It just didn't execute.play()when I did.I have installed your 2.2.3 fix and it seems to work perfectly. Thanks!
@csongorb thanks for trying out the test build! v2.2.3 is now also published under the 'latest' tag, so the fixes should become available for everyone through the Contribution Manager over the next couple of days...
In order to sync each frame of an animation with a sound in the background, I had been using the following code in draw():
frmrate was set to 30 or 60, depending on my desired output framerate.
2.2.1 was able to call this successfully each time draw() was called, allowing me to save each frame as it was updated by the sound.
When I updated to 2.2.2, however, it seems as though .cue() would only work occasionally. Instead of a consistent choppiness (it's syncing 30 - 60 times a second, after all), I would see no response and hear no sound until the occasional blip. Another might follow a few seconds later. This seemed to happen at random, but did seem to be following along with the sound, though it was not able to consistently draw and play it audibly.
I noticed also that I could not call .cue() in setup() either. It would result in a silent and empty frame unless I also called .play() in draw(),
like so...
...in spite of already having called it in setup(). Calling .cue() then .play() in setup worked perfectly well in 2.2.1, but would not work in 2.2.2 for some reason. .cue() could be called in draw(), but not every frame, like it was able to do in 2.2.1.
Honestly, I'm surprised this issue hasn't been brought up yet. It seems like that's some pretty basic .cue() functionality, right?
I tried reinstalling 2.2.2, restarting the computer, and reinstalling Processing (not necessarily in that order). No improvement. Once I reinstalled 2.2.1, everything worked as intended again.