He there. I'm beginning to get acquainted with music production under
linux and there's a question that bugs me about pure-data.

Some argue that one strength of music production under linux is the modular
approach given by the jack audio server; it allows completely independent apps to route signals to each other, etc. etc. The major problem with this is a complete lack of cohesion: there is the classical foss paradigm, you have xyz apps, each providing the appoximately the same functions as the other, are coded in perhaps a different languages, have their trade-offs here and there and then A is missing some must-have feature of B and conversely; lots efforts are dissipated, UIs are a chaos, the softwares architectures are redundant with bugs, duplicated semi-polished features, etc.

Then you have pure data, which at first glance, looks like a high-level, integrated audio developement environnement, just the unified framework one would need to build and enhance a perfect music creation environnement. Yet as it looks (forgive the short sighted vision of a newbie) pd has remained a developement-only platform that has yet to yield it's fruit to that other end of the spectrum of the music community which interests are more focused on the architecture of rythms and melodies instead of the software generating them.

So my question is this: is there such environment and if not, why not?

Hmm. In the case it wasn't made clear enough, I do not suggest a reduction of PD to a more constrained environment but rather, allow it to be integrated in a richer context that would allow it to reach a broader audience - the only constraint needed for this, is, in a way, a common language between the layers.

Anyways, I don't think I can make the general idea clearer. If any developer is interested in the endeavor, I'd be glad to contribute - note that I'm not deluded enough to think I can lift such a project all by myself as I have other, more pressing concerns for the moment.

Again, my point was to poke to see if there is - and perhaps ignit - some interest in this direction. If there's none, then I'm beating a dead horse, linux audio is just fine and dandy... I'll just boot to where I can find a decent grand piano.

"I do feel like its only a matter of pd developers making an understandable gui and then writing nice picture tutorials on how to make it work for the musicians"

Indeed my plea is mainly concerning current PD developers and while the programming of a unified GUI is certainly one of the matters I'm concerned with, "nice picture tutorials" cannot compensate for a unified framework with clearly and well separated layers that would encapsulate the information level you have to cope with while doing your stuff. You could build a synth in C - or assembly for that matter, having a nice C or assembly tutorial under your hand, but I guess that would be overkill, right?

"Also, in defense of the pd visuals, I find the minimalist vectors ten times more attractive than the vast majority of designs vst developers throw together"

Minimalism is in no danger here - and I don't think it should be of any concern for the moment. An aspect I would like to consider though, is what information should be allowed to pass through the GUI.

I will attempt to precise the architecture I'm thinking of to ensure we'll really be talking about the same thing.

Layer 1.

The music production environment GUI. Featuring the usual stuff: multi-track classical/midi partition editor, instruments bank, pre/post processing effects chaining, etc. Most importantly, controls should be displayed and respond in a uniform way, there also should be a high level script-language/gui application for designing the interface of new instruments/effects/etc.

Layer 2 (i.e.: Pure Data)

A Self like programming language, highest level as possible, for quickly designing and prototyping new instruments/effects, to be incorporated into level 1.

Layer 3.

An application framework for extending the capabilities of layer 1 and 2.

Now what I find appealing in this model, is that every significant level of the music creation process would be sufficiently organized to be tempered with while remaining on the level one is addressing (i.e.: Although the possibility remains, a musician interested only in composing melodies and stuff, won't have to cope with the low-end technical details of the instruments he's using; the instrument designer won't have to care about the underlying programming framework, etc, etc.)

Now to address some of you comments:

"it's difficult to integrate PD into other music production environments"

• I don't see the need to integrate PD in other music production environment, as to me, PD shouldn't be a mere plugin but the foundation of a music production env.

"to make complete works in pd alone requires fairly significant knowledge and effort."

• As stated above, PD shouldn't be the place for making a complete musical work, but rather for designing one's instruments.

"pd's gui is incredibly primitive" and
" i would love to build a basic multitrack DAW in pd, but the gui would be maxed out way too quickly."

True, and this is why the layer 1 is really needed.

Now, I certainly don't consider the instrument engineering part of music as to be a waste of time; although it would be a waste of time if those instruments couldn't be used by anyone except their makers - and the same goes for any program. I know these suggestions I'm rambling about are probably not new nor would they probably cause any revolution in linux audio, I only hope it could stand as a direction the ones interested in developing PD a little further might seriously consider.

Cheers to Moog and Scott.