hey thanks everybody!

one question for malte. ...on my system.. os X ... a lot of the subpatches in your worskhop synths, drums etc,,, they don't open.

any idea why?

Maybe you could copy the output of the terminal window, which should say which objects and abstractions aren't loading properly. Look for:

this_is_a_bad_object_name_etc_blah ... couldn't create

Then we can figure out if these externals can be built for OSX.

I haven't looked at Malte's patches in a while, but it could also be that he has some abstractions in a different folder than the patch is opening from, in which case you'll have to locate the abstraction and manually add the path to it.

d.

dorkvac bazynchnai wrote:

same here, but I think it's because I don't have the right externals installed.

It would be nice if the patches included a comment about which external they depend on.

hard off wrote:

...

hey thanks everybody!

one question for malte. ...on my system.. os X ... a lot of the subpatches in your worskhop synths, drums etc,,, they don't open.

any idea why?

aha!

malte's subpatches actually ARE opening. just WAY offscreen.

2nd line of [snaredrum pd]

#N canvas 1173 370 530 324 SnareDrum 1;

We should get all of these patches into CVS so that they'll all be in
place and they can be distributed with Pd-extended.

.hc

On Dec 12, 2005, at 4:26 PM, Malte Steiner wrote:

Hi,

I have to look on my own but they dont rely on any fancy external, its
an abstraction when I remember right. The patches where built on Mac
OSX by the way...

I keep reporting,

Malte

--
Malte Steiner media art + development -www.block4.com-

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

               ¡El pueblo unido jamás será vencido!

Hallo, hard off hat gesagt: // hard off wrote:

basically what i'm doing is going through all these patches, and taking out all the named send-recieves (for clarity and ease of use) .. taking off all the gui interfaces (so it's easier to see what's going on) ... putting everything into subpatches rather than abstractions (again, for clarity and ease of use, and also simple cut and paste flexibility)

Why are you converting abstractions to subpatches? Aren't abstractions much easier to reuse than having to cut and past a subpatch? At least I think so.

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:

On Wed, 14 Dec 2005, Frank Barknecht wrote:

...

Why are you converting abstractions to subpatches? Aren't abstractions much easier to reuse than having to cut and past a subpatch? At least I think so.

BTW, in GridFlow, a damn lot of useful tidbits are still only subpatches instead of abstractions, and there's a reason why: for some things, there are so many possible variants one may possibly want, that for easily reusing an abstraction you need to make a private copy and make your own changes. It's possible to include a lot of variants inside one abstraction by using extra inlets and args, but sometimes it would just lead to 13 inlets and 42 arguments and that's... ok I'm exaggerating. But still, often, I think I have to make an abstraction for a certain thing, but then I'm confused about what its feature set should be and how configurable it should be, and then it becomes a mess and then I delete the file and go back to my subpatches...

But every subpatch lives in an "abstraction" (as in "file", not as in "coding style") anyway. If I look for some operation that I patched in the past for some project, then I can use many tools (find, locate, "Search this computer") to locate it, if it's an abstraction. If it's hidden inside another patch I have a hard time finding that exponential scale of 5 sfsfsf lists I did months ago. "locate interpolate | grep pd$" will lead me right to it.

So to reuse subpatches a lot one would need to have one or more "master patches" open all the time. IMO it's much easier to just use one or more "master directories" for possibly useful abstractions.

And: *If* the patches already are abstractions, I really cannot understand why they should be de-evolved into subpatches and stuffed into a single file. This seems like a step backwards or at least sideways.

Subpatches have their place, they are important for example to lay out a clear route through an algorithm. For example I often use subpatches that only contain a *single* object just to give something a better name for this context, like using [pd getPosition] instead of [tabread $0-pos]. I also often start patches by laying out several empty subpatches and connecting them:

[pd getPosition] | [pd addForces] | [pd convertToFrequency]

Then these are filled as I go on.

However as soon as something needs to be reused several times, a subpatch is not appropriate anymore except for one-off patches. This then is the place for an abstraction.

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

On Wed, 14 Dec 2005, Georg Holzmann wrote:

...

However as soon as something needs to be reused several times, a subpatch is not appropriate anymore except for one-off patches. This then is the place for an abstraction.

yes, I think that's the point. It's like you always say, matju, "do it once and only once" ... ;)

Shit! Someone who actually listen to my conference talks! Hjelp!

What I was trying to say is that even though I'd like to do each thing once and only once (http://c2.com/cgi/wiki?OnceAndOnlyOnce), sometimes there's a problem with what "each thing" is. Sometimes I'd have many different abstractions with the same name because they all do different things really, and because it happens that I want to customise the would-be abstraction as soon as I instantiate it, the OAOO-style reuse doesn't happen, and the clipboard-style reuse happens instead.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

People might be able to help you more if you make your question a bit more specific, and describe, for example, what form of synthesis you want to use?

youre right, but the matter is that i really dont know what kind of synthesis i want. I just know that what i want are very short sounds with enough information inside. I want very characteristic sounds but not too much intrusive. The interest for find a Synth is for put the same numeric values that i used for control the duration relations in the diferent parameters like frequency, number of partials, volume of each partial(i was thinking firstly in aditive).

That is all specific i can be for now, sorry for that, and thank you,

Josué.

On Wed, 14 Dec 2005, Hans-Christoph Steiner wrote:

You could write a suite of objects instead of one monolithic one with 13 inlets and 42 arguments. Then you get the advantages of code reuse without having to mess with subpatches.

Yeah, but what happens in this case is that this suite of abstractions would have one or two objects each (plus [inlet]s and [outlet]s). I'm talking about the case when most of the patching may count as configuration.

Besides, etymologically, "configuration" is "the picture that things make when together", which is a pretty good description of what a pd patch is...

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada