Hey guys,

Attached is an (I think) attractive waveform display built with data structures. It allows you to zoom in and out/scroll, change the colors, resize, and draw a selection box.

The .zip contains the actual abstraction, [waveform.mmb], and its helpfile. It also has a couple of abstractions that either it or the helpfile uses. I think I've posted them all here before, but I've included them anyway so you don't have to search for them.

I've been working on this on and off for about a year, and I've finally gotten it to where it's worth sharing. There's still more features I'd like to add (like snapping the selection, adding a time display, and changing to different units), but I think it's still useful in its current state. And I might not have much time to work on it for a while.

http://www.pdpatchrepo.info/hurleur/waveform.mmb.zip

oh, i never realised that [until] might be such a bottleneck.

i just took out the iem objects and replaced with an [until] structure, and it's slow and clunky like my old editor was.

then, i tried replacing [until] with a counter/bang based loop, but of course that sends the stack overflow detector crazy and crashes pd.

extended it is then. gives me a good excuse to use the [playlist] external for file loading too.

Really nice !

I'm changing some parts of it in order to make it behave nicier with automation-like tables (only one trace, vertical zooming).

I'll have to dig into pd structures, for easy tasks like this it's not a problem, but I'm thinking of the future, so I have a question : would it be possible to use two traces, one of them beeing 'unreacheable' with the mouse whilst the other one could be edited ? This way I could draw an automation curve and edit it keeping a visual on the initial shape.

I've always had problems with 'z-plane' problems ; in 'normal-gui' programming the best that I could do is surimposing a moving slider (playing head) over an automation curve that I could still edit, but it happened to take me some time to delete and re-create objects in order to avoid masking an element with another (know what I mean ? )

Thus my second question would be : is it possible to surimpose many more non-masking gui objects using pd structures ? It would be a big step in my gui work !

Thank you,

Nau

This amazing! it works great

and the hsliders with several modes of interaction are also amazing. Another great contribution, thank you!

Hi there,

I'm trying to integrate a very slightly modified version of this waveform display to work with "automation-like" tables. Major requirements are vertical scaling ability and dumping a mouse-drawn curve into a table.

Data structures are not yet easy to handle for me, and I'm learning every day, thanks for that. This is a nice abstraction to use as a tutorial.
By now I am able to use it with a single 'trace', and zoom vertically, at the cost of scaling the data itself, as it seemed impossible to me to overcome the fact that you can't send messages to a graph to change its vertical range. Afterwards I realized there could be a better way (09.scaling.pd), but it is still over my head and didn't had the time to implement it.

I know that retreiving data from a structure is possible using 'get'. I'd like to make the changes made with the mouse in the structure be saved back into a conventional table, on a 'bang'. In 'usual' tables copy operation or scaling I can use 'until' or 'counter' loops or even use an external. So I can imagine that '02.getting.data.pd' is the key to transpose this in 'data structures'.

Maelstorm, are there 'advices' that could come into your mind regarding this operation using your waveform display abstraction ?

A few other questions. Maelstorm, I can't see a difference (gui point of view) switching between values as far apart as 2000 and 20 for 'sampsperblock' argument. Could you briefly explain what this arg does ?
I noticed that horizontal size can't exceed 1000. Is there a workaround ?

Thank you so much,

Nau

Using this abstraction to draw in data probably won't be the easiest thing. One pixel can represent many samples, so you'd have to decide on some interpolation approach when the display isn't one-to-one, and you'd also have to make sure the other samples don't get changed at all.

If you connect a [struct] to [print] you can see that it notifies when the mouse clicks on an array. But it doesn't tell you where it clicks or how much it has changed. My thoughts right now would be to use that message to start polling [MouseState] and use the distance changed in pixels once the mouse button is released to determine how much of the array should be used for updating the automation @nau said:

A few other questions. Maelstorm, I can't see a difference (gui point of view) switching between values as far apart as 2000 and 20 for 'sampsperblock' argument. Could you briefly explain what this arg does ?

I noticed that horizontal size can't exceed 1000. Is there a workaround ?

Thank you very much Maelstorm.

Indeed the horizontal subdiscretisation is an issue in a drawing context.
I'll let this apart for the moment, but as writing staircaises is not an issue to me (because if I understand well zooming and re-editing zones could allow me major control) I think I could try later, collecting in an array the positions of the modified values to avoid messing with the others (updated with each drawing operation (bound to [metro 50]). This scenario wouldn't need polling the mouse position, or am I wrong ?

Nau

Hi there,

sending [hrslider.mmb] and [waveform.mmb] send/receive some 'names setting messages', I can hide nearly every connection to/from these objects in my gui.

But these very messages have to be sent to 'default' "$0-inlet12' of two different instances of [hrslider.mmb], each one with its own '$0'.
I can't find a way to 'reach' them with messages without drawing a cable, used only for this very first in/outlets renaming operation.

Is there an elegant way of doing better ? Should I use a method like the one proposed by billystiltner in http://puredata.hurleur.com/sujet-5853-abstraction-why-use-etc ?. Or maybe am I missing something (again ) ?

Nau

Yeah, it currently sucks with the way Pd is set up now and I wasn't really sure what the best way to go would be. My workaround has been to put [waveform.mmb] and the rsliders in a GOP subpatch and [loadbang] a message box with the send/receive messages to them. That way the connections will at least be hidden. But it's not really ideal because you could just as easily connect an actually [send] to the inlets and hide them that way as well.

I realize now that the best way is to just pass the send/receive names as arguments, but I didn't want to force the user to provide them, and at the time I wasn't sure how to handle it if they weren't provided. Pd-extended 0,43 now has the iemguts library that allows you to make your own properties dialogs for abstractions that can update the abstraction's arguments. So I've been tinkering with using iemguts with my gui abstractions and have had success (though it does take more patching than I anticipated), except it seems that dealing with $ arguments is still a bit funky. You have to save the containing patch and reload it for them to take effect, which is annoying. But I think it still beats patching in a bunch of message boxes and [loadbang]ing them.

Thank you for your thoughts and the iemguts reference, I wasn't aware of that.