PURE DATA forum~

...that deal with pure data

You are not logged in.

#1 2011-07-05 22:27:23

Maelstorm
Administrator

Waveform display

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.


.mmb   |   My library

Attachments:
Attachment Icon waveform.mmb.zip, Size: 18,282 bytes, Downloads: 442

Offline

 

#2 2011-07-06 10:27:00

mod
Administrator

Re: Waveform display

Beautiful!  That's awesome how it works with the hsliders you made.  If i use it on a drumloop or something, and select 1 beat region, it's then very easy just to shift that region to select another area of equal length.  Fantabulastic!

The data structure display is much smoother, better looking, and faster than a normal array would be too. 

I made a sound editor in pd a couple of years ago, but never got the zoom or scrolling thing worked out.  The display was not the best...this sorts out those issues, and also adds more funtionality than i had before.  Gonna go make a quick couple of abstractions to make it all vanilla (heh heh), then plug it into my sound editor.  Wooh!

Offline

 

#3 2011-07-06 10:32:57

mod
Administrator

Re: Waveform display

sorry, one more post.  This patch actually has me sitting here giggling. You don't know how many hours i spent cutting up samples with my dodgy old array-based GUI.  The fluidity of the zoom on this is just great.  Absolutely love it!

Offline

 

#4 2011-07-06 21:10:02

Maelstorm
Administrator

Re: Waveform display

Thanks, mod, glad you like it! I remember your wave editor. I found it shortly after joining the forum. It was the first thing I saw that made me go, "Wow, you can actually make something REAL in Pd!"

Just a heads up, though, unless you find a better way to do it than I did, making it fully vanilla might be disappointing. I really tried hard to make this vanilla-friendly, but it just wasn't happening. [until] is just way to slow. When loading large soundfiles, I was literally sitting their a good 45 seconds or more waiting for the waveform to draw. The audio would drop out and my laptop fans kicked into high gear. I ended up using the iem_tab objects because they can handle large groups of numbers much faster.

I only mention it because that was the main reason it took me so long to make this useable. But, if you do give it a go, finding an efficient alternative to [tab_min_index] and [tab_max_index] is going to be the tricky part. If you do find a solution, let me know!


.mmb   |   My library

Offline

 

#5 2011-07-06 21:17:03

Maelstorm
Administrator

Re: Waveform display

I just noticed the helpfile says you can't zoom in closer than one sample per pixel. That's actually not true. I fixed that a couple of weeks ago and forgot to change the helpfile. I just re-uploaded with the corrected one.


.mmb   |   My library

Offline

 

#6 2011-07-07 07:50:38

mod
Administrator

Re: Waveform display

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.

Offline

 

#7 2012-04-28 00:15:17

nau
Member

Re: Waveform display

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

Offline

 

#8 2012-04-28 13:48:04

Re: Waveform display

This amazing! it works great :)

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

Offline

 

#9 2012-05-04 00:44:10

nau
Member

Re: Waveform display

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

Last edited by nau (2012-05-04 00:45:48)

Offline

 

#10 2012-05-04 21:35:25

Maelstorm
Administrator

Re: Waveform display

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 [table]. But I'm not sure how to determine which array element the mouse starts at.

As far as the vertical zooming goes, I'm pretty sure changing the "Y units per pixel" argument in [donecanvasdialog( can be used as a cheap way to do it (it's the second argument). Then moving the position of the scalar that the array is attached to could be used as a simple vertical scroll. It may end up drawing outside of the display, though.

nau wrote:

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 ?

You can ignore it for now. It doesn't do anything. Originally, when I was using [until] to read the tables, this was meant to limit how much of the display to make per block to try and prevent the audio from dropping out. [until] was too slow, so it would cause noticeable silences for even small updates, and it was just awful for longer samples. But once I discovered iem_tab and how much faster it was at grabbing sections of tables, I abandoned this. I may go back to it at some, because drop-outs can still happen with longer files or multiple [waveform.mmb]s.

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

I believe this limitation is hard-coded into the data structure arrays. The only workaround I can think of would be to have a second array in the [struct] that is positioned at the end of the first.


.mmb   |   My library

Offline

 

#11 2012-05-06 00:17:09

nau
Member

Re: Waveform display

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

Offline

 

#12 2012-05-07 00:28:26

nau
Member

Re: Waveform display

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- … hy-use-etc  ?.  Or maybe am I missing something (again ;-)) ?

Nau

Last edited by nau (2012-05-07 00:29:17)

Offline

 

#13 2012-05-07 02:59:33

Maelstorm
Administrator

Re: Waveform display

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.


.mmb   |   My library

Offline

 

#14 2012-05-08 22:16:12

nau
Member

Re: Waveform display

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

Offline

 

Board footer

Powered by PunBB
Copyright 20022005 Rickard Andersson


pd.webring info