i've encountered an annoying problem with the waveform~ object - i as wondering if anyone has had the same thing and has a workaround?

my main performance patch has 5 subpatches, which open up to nearly-full-screen windows (using keyboard keys to open them - "front" -> "thispatcher"). each subpatch has a buffer for sound (record or replace) and some have smaller buffers for lookup tables, windowing etc. each window has a waveform~ object displaying its sound buffer.

sometimes when i open the patch, the waveform objects are mixed up! they display the wrong buffers, e.g. one that should show a sound wave is showing a window shape, or it shows a sound that i tried to load in another window. sonically everything is fine, the sounds are actually in the buffers they're supposed to be in, just the waveforms are referencing wrong.

i've changed them all with the "buffer object name" attribute in the inspector, and even sending a "set " message doesn't work, they don't change - they think they're already showing that buffer.

i thought it was because i'd copied and pasted the waveform objects from patch to patch (to keep them the same size) before changing the names, so i replaced them all with new ones - but lo and behold it still does it.

quitting max and starting again *OFTEN* sorts the problem out, but not always!

the problem is -
sometimes when i open the patch, the waveform objects are mixed up! they display the wrong buffers, e.g. one that should show a sound wave is showing a window shape, or it shows a sound that i tried to load in another window. sonically everything is fine, the sounds are actually in the buffers they're supposed to be in, just the waveforms are referencing wrong.

quitting max and starting again *OFTEN* sorts the problem out, but not always! 

anyone having the same problem?
any help or suggestions appreciated.

waveforms-showing-wrong-buffers

I've noticed this a lot too. I'm using bpatchers with waveform~ and each has a name like #1wave, with different args for each. I'll load a file into one and often the others will also load without asking. Or the waveform isn't visually correct, though the sound is fine. Not sure what to do about it. The buffer~ and groove~ #1wave are fine, they load as 1wave, 2wave, etc. but the waveform often will show the wrong buffer, though the sound is right.

Any thoughts from Cycling on this, it's kind of strange...

I have encountered this problem as well; very strange, but I assume that it's going to get fixed soon.

If one of you could come up with a small, well commented patch which shows the problem clearly we'll definitely have a look at it.

What's strange about this: I can't reproduce it. The bug seems to depend on other patches I had open when it manifested itself and I don't remember which ones. That's why I first kept quiet until reading about other people having the same problem.

What's strange about this: I can't reproduce it.

Since waveform~ was introduce first, there's always been this issue. Once in every 10 or 20 or so instances (I'm not too heavy a user of the object) it goes wrong. Behavior that I have observed is not updating the display at all either upon loading a sound file or while recording. One of the solutions that sort of worked, I think to remember, is to set the name of the waveform to a non existing buffer and then back to the buffer it was linked to originally. On several occasion I decided to try to find which steps leads to this behavior, but I haven't been able to come up with anything. I know this doesn't help a whole lot.

Quote:What's strange about this: I can't reproduce it.

it's a relief that i'm not the only one...

same here, it's really erratic. sometimes does it, sometimes doesn't - i would have posted a patch in which it consistently happens, but i haven't got one & don't know how to make one!

@AndrewPask - i could send you my patch in which it's often happening - it's far from small i'm afraid.

@jvkr - re: "since waveform first introduced" this never happened to me in max 4.6, and i was using waveform~ in much the same way.

it's a relief that i'm not the only one... 

@jvkr - re: "since waveform first introduced" this never happened to me in max 4.6, and i was using waveform~ in much the same way.


bump, and update, with a slight workaround -

i suspect the problem is having lots of waveforms appear at the same time on patch startup. i've switched from embedding my patches as subpatchers to loading them one-by-one, using "load thingy.maxpat" to pcontrol. still on loadbang, but with 10ms delays between loads. so far the waveform~ confusion hasn't happened - but i'm still wary!

this isn't really an explanation, the problem's still there and it would still be nice if it was looked into!

bump, and update, with a slight workaround -
i suspect the problem is having lots of waveforms appear at the same time on patch startup. i've switched from embedding my patches as subpatchers to loading them one-by-one, using "load thingy.maxpat" to pcontrol. still on loadbang, but with 10ms delays between loads. so far the waveform~ confusion hasn't happened - but i'm still wary!

this isn't really an explanation, the problem's still there and it would still be nice if it was looked into!


While working on a patch that does show erratic behavior, I managed to figure out at least the following. If selection start and end are set with a loadbang, to a waveform that refers to an empty buffer that has been defined without length argument, it might happen (not always) that once a buffer has been loaded using the replace message, the waveform object has zoomed to the first sample or so, even when zoom has never been set. Using the set message with a non existing buffername and then set with the actual buffer name makes it zoom to the entire buffer again.

+1 I regularly have this problem with waveform~ showing wrong buffers too. And i can't reproduce it reliably either.

After reading this thread i have a fix that seems to be working. In the subpatches, the set messages sent to the waveviews are delayed by a random number of ms, so that the 'set's in subpatches fire at different times. So far this seems to have fixed the mixups that were happening in the patch i'm working on at the moment.

do you also read 4 different soundfiles from disk via loadbang?

we recently had a similar discussion here, problems on load when there are multiple disk accesses.

I've encountered this as well, though also not reliably.

I had 2 buffers and 2 waveforms, with the display length of each being set by a signal>snapshot~. I had to delete-undo the offending waveform for it to work.

I had 2 buffers and 2 waveforms, with the display length of each being set by a signal>snapshot~.  I had to delete-undo the offending waveform for it to work.


I've been having this problem too - mostly when I open and close multiple patchers with waveform~s in them. Sometimes when I open another patch the currently open patch will show the waveform from the newly open patch, then when I close the previously open patch, the waveform~ on the newly opened patch will go blank (not just no waveform, but no time or tick marks either).

Sometimes is really an issue if the patch depends on values gotten from the waveform~.

Mostly for me this has happened with patches that started out as the same patch, then were saved to separate files and subsequently modified independently (ie several audio cue trigger patches for different pieces on the same performance).

For final versions, I managed to greatly reduce how often the waveform~ problem happens (but not eliminate it completely) by re-arranging and re-instantiating objects. But before I did that I saved these versions which almost always I can get to display the bug:

http://arvidtp.net/dropbox/max/waveform-wrong-buffer-atp.zip

Open one, then open the other, the close the original one, then re-open it, then close the 2nd one, then re-open it, etc etc... and I bet you'll see the waveform~s "becoming each other", disappearing, etc. Both patches load audio files into their respective buffers at loadbang.

The patches don't really make sense because I greatly abbreviated the audio files for this download, but they do display this behavior. I also reversed one of the audio files so it would be obvious by looking at the waveform when something is wrong.

To deter confusion: I used a transparent waveform~ above the main one loaded with the same buffer to highlight the part of the file that will play on the next trigger. That's what that part is.

Hope these are somewhat helpful in getting to the bottom of this.

For final versions, I managed to greatly reduce how often the waveform~ problem happens (but not eliminate it completely) by  re-arranging and re-instantiating objects. But before I did that I saved these versions which almost always I can get to display the bug:

http://arvidtp.net/dropbox/max/waveform-wrong-buffer-atp.zip (6.3 MB)

Hope these are somewhat helpful in getting to the bottom of this. 

I see what's happening - seems like this begins happening without fail when you accidentally open the same patch twice (that has a waveform~). From then on I immediately have this bug between the two patches until I quit and restart max. Try that with the patches I posted on the previous post: open one twice, then go about opening and closing them (so that both are usually open at once).

Too bad onecopy only works from the extras menu...

waveform~ sometimes links to the wrong buffer after a buffer is created, destroyed and then re-created with the same symbol name. (That would happen when you close and then re-open a patch with a buffer in it, as you described.) One way to finesse this problem is to set your waveform display to "nil" and then set it to point to the buffer you actually want to display.

Thanks Eric - could you give an example? Not sure I am doing what you had in mind - this is what I come up with:

This seems to help a little - it at least takes more opening and closing before the problem manifests itself, but it does not seem to solve the problem when I open multiple copies of a single patch.

I think you need to take a bang from the right outlet of buffer~. Otherwise, the patch looks good.

Hopefully the attached patches will make this clearer.

oops yes - i was taking the right outlet in my actual patch - just screwed this simple one up

I see what you mean - have a reset button on each waveform~.

What has been the real problem for me is accidentally opening two copies of one patch I think - then things just get screwy. So one could just press the reset button. Cool.

But - I always want to make it as easy as possible for myself onstage - when I am on stage with a computer in front of me, trying to use a mouse, I suddenly become really really forgetful and stupid. It's actually quite amazing.

So - I've come up with an automated way of doing this - it requires a small amount of extra complexity, but might be worth it and could easily become an abstraction with an argument. With this it seems I can open and close as many conflicting patchers and mutliple instances of the same patchers with waveform~s as I want, and they always show the correct buffer in them.

oops yes - i was taking the right outlet in my actual patch - just screwed this simple one up 

waveform~s showing wrong buffers