I am just starting out with pureData, reading what I can, and trying to figure out how the whole thing work.

But, there is one change I think could be useful, to the system.
I am not sure if this is the right place, but here goes.

In the world of electronics, sliders/pot-meters usually have a range of say 0 - 1. But they usually also have two outputs. On the one side you would get 0 - 1, and on the other one you would get the inverse.

So when a slider is all the way to the left it would be 0 on the left output, and 1 on the right output. And vice versa.

Now, this could of course be done by adding some calculations to an extra output connection, but then you would have to adjust more stuff if you edit the range of the slider.

Just a suggestion, or though.

// Greger
http://gregerstoltnilsen.net/

Do you mean this? Open help-elecSlider.pd
This needs to be added to PD's path. To create an instance create a new object named elecSlider

http://www.pdpatchrepo.info/hurleur/elecSlider.zip

Now, this could of course be done by adding some calculations to an extra output connection, but then you would have to adjust more stuff if you edit the range of the slider.

You could make the slider dynamic by passing the instance arguments when you create it: [elecSlider 20] could make it 0-20. You'd have to take that argument inside the abstraction and send it in a mesage to the slider: [ fooname_rcv range 0 $1 ( .............check the help patch for sliders

Sorry if this sounds a bit tangental - if you are starting out, can I recommend that you nail State Saving in your patches sooner rather than later? Only because it can get rather tiresome losing values every time you close a patch - if the patch is complex with lots of values then you can imagine the ballache of getting back yo that state again and again.

I only say this as i wish i had not put this off for so long, as it makes using Pd much much more productive.

What would be the best way to do State Saving with abstraction though? Just setting INIT in the slider doesn't do it since that would it wouldn't work in an instance by instance basis.

totally, i actually starting writing about that, but then halted as I thought poor gregor would get information overload!

ok...i've opened a can of worms here.......

Personally I use SSSAD for abstractions, or rather Chris McCormicks version of it. There is also a recent addition called [presetstore ] where by you can create multiple presets in the patch. Ive got into the habit of making my abstractions sssad ready - i doesn't take that much extra when you get into it. Its fecking neat i think.
http://mccormick.cx/projects/s-abstractions/
http://lists.puredata.info/pipermail/pd-list/2007-04/049452.html (for [presetstore] )

Theres another idea in the BOT abstractions (thats Bag of TRicks) that is similar to SSSAD, in that it uses messages, but instead of being centralized, you attach a message box to the input and output of each abstraction. See
http://puredata.hurleur.com/sujet-268-announcing-bagoftricks

I think I will revisit this when I get a better grasp of the whole pureData-concept.
Coming from a text-based-programming background this is all a bit confusing, a bit annoying, but also fun.

Anyway, yes, saturno, I think you are onto what I was talking about.

@greger said:

I think I will revisit this when I get a better grasp of the whole pureData-concept.
Coming from a text-based-programming background this is all a bit confusing, a bit annoying, but also fun

yeh sorry mate :-/ too much at once

hey there,

yes boonier is very right: i've been building my own preset-saving system (with tables) just so as to avoid understanding sssad (still no tutorial or easy help in there, and it's a big chunk), and i get blocked every ounce in a while ..... my own system works fine for abstractions, but now that i've got complex patches with many abstractions, it's a real problem...... do you know where i can find more info on that sssad? i mean so as to undertsand it?
cheers