Is it possible to change the 'Graph On Parent' dimensions from within the patch?

For instance, I'd like to create a resize-able GUI abstraction. But I'm not sure how to address the patch to set things like size and position.

On a related note, being able to set the size/pos of the editor windows via msg would be pretty cool too.

I'd be grateful to anyone who can shed some light on this for me.

Thanks

I remember seeing a while back that it was possible to tell pd to include a file path from within the patch with a message, but I've had no luck finding info about this with Google. Something like [; pd include path/to/include(.
Anyone know?

Thanks

Since you're not using the value for anything after you check to see if it's over 100, you don't need to use [spigot] at all. I'd use [select], like this.

http://www.pdpatchrepo.info/hurleur/2notes-b.pd

Yep.

Here's one way.

http://www.pdpatchrepo.info/hurleur/conditional.pd

This.

http://www.pdpatchrepo.info/hurleur/elden.pd

Here's an abstraction that works, I added a few comments inside. I don't use extended, so I'm not sure if it has a naming conflict, but you can always rename it to whatever you like.

http://www.pdpatchrepo.info/hurleur/rescale.pd

...
|
| [!= 0]
| |
[spigot]
|
...

In PD go to Help -> Browser

There were some execution order problems with the counter you posted. A trigger object solved the problem.

http://www.pdpatchrepo.info/hurleur/counter-fixed.pd

Here are some counters that should help.

http://www.pdpatchrepo.info/hurleur/counter-example.pd

Here's a less elegant, but vanilla solution.

http://www.pdpatchrepo.info/hurleur/Lottery.pd

It looks to me like he's using the delay to play each grain backwards. That's why the phasor is inverted.

Check out the help file for

.

You can use [moses] instead of the 2 [spigot]s. Like so.

http://www.pdpatchrepo.info/hurleur/Expo.pd

Here's a quick mod of your patch that shows what I mean.

http://www.pdpatchrepo.info/hurleur/Exponential_Scale.pd

Make the input range for the base of the exponent zero to one. This way the output will always be zero to one, but the curve will vary with the exponent. Then just rescale zero to one to whatever you need it to be.

Oh, and be sure to stick a [abs] before the [> ].

How about setting a lower limit to the output?

Something like

[hid]
|
[t f f]
| |
| [> 5] (for example)
| /

• The tradeoff is that you'll lose a little precision, but hopefully you'll be able to find a value for the threshold that's low enough that you don't feel it, but high enough that it will block out the noise.

If you can use tables to store the sounds, you could set up something using [until], a counter and [tabread]/[tabwrite] to process the samples as fast as possible. Keep in mind that it'll block until the processing is done, which means you'll probably have audio dropouts if you're listening at the same time. Not sure if that's a problem for you or not.

mmb-
I think of it a lot like access modifiers in other languages. $0 is for private fields, $1 is for public. Often times $1 will contain its parent's $0, but still followed by some sort of descriptive name.
Instead of sends and receives I use an abstraction based around the value object, which also allows me to think in a more 'classical' manner. Fields can be accessed as needed by name and it combines s/r functionality into one parameter object.
I also have everything built around a single 'global' patch with a subpatch called [interface] that contains all the parameter objects used globally, for easy reference and copying. In fact, each object created for use in this environment contains it's own [interface]. This way, when creating a new object, I know I can just type something like [x TEMPO] and be sure it's using the same tempo as everything else, and that any change to tempo anywhere will be recognized as it happens.

But this is a little deeper than ksujata was looking for I think.
It really all boils down to preference, and what you can make pd do for you.