Skip to content

.cue() cannot be called very quickly in 2.2.2. It works as intended in 2.2.1, however. #40

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bpeterson37 opened this issue Jul 19, 2019 · 5 comments
Labels
bug Something isn't working

Comments

@bpeterson37
Copy link

bpeterson37 commented Jul 19, 2019

In order to sync each frame of an animation with a sound in the background, I had been using the following code in draw():

frameCue = frameCount/frmrate;
in.cue(frameCue);
in.play();

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...

if (!in.isPlaying()) {
    in.play();
}

...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.

@kevinstadler kevinstadler added the bug Something isn't working label Jul 20, 2019
@kevinstadler
Copy link
Collaborator

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 that isPlaying() 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!

@bpeterson37
Copy link
Author

bpeterson37 commented Jul 20, 2019

Not a prob.

Does your code rely on other calls to .isPlaying()?

.isPlaying() was only used when .cue() would not work in setup(), 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
   . . . 

@kevinstadler
Copy link
Collaborator

@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 your Processing/libraries/ folder, replacing the content of the existing sound/ folder.

I also fixed a small issue with jump() which should now have the exact same effect as calling cue() and play() directly after each other, so you should be able to use those interchangeably.

@csongorb
Copy link

csongorb commented Aug 5, 2019

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!

@kevinstadler
Copy link
Collaborator

@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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants