On 09/12/14 20:41, Jonathan Wilkes wrote:
Essentially, you want functionality inside Pd so that you can draw connections between boxes in order to create a program. Creative people often want to make GUIs, and making GUIs is hard. So it makes sense to have functionality within Pd that lets people make GUIs with boxes and connections. If the data flowing over the wires can just as easily flow to the signal graph as it can to the GUI properties, the benefits are obvious.
Of course, I'm not saying we shouldn't have GUIs in Pd, which we do. The aesthetics of those GUIs is something different (I have always liked them :-) - and hard to really fit into the typical toolkits even (proprietary and non) audio/multimedia programmes have non-standard GUIs think Max MSP, but also DAWs, Blender...
Inter-process communication is great. But it adds an enormous amount of difficulty for the non-technical user, and many creative types are non-technical (read: not sysadmins). IPC adds complexity; but the bigger issue is that most IPC interfaces are designed for sysadmins. If they were designed with non-technical users in mind, then you'd be able to send me some standard, cross-platform file type which I could (safely) click to open both iannix and Pd and create the connection between them.
I don't think opening two programmes and (e.g.Iannix and Pd) and knowing that you can 'connect' the output of one programme to another one is a highly technical concept. Maybe it is not so typical, especially for non-linux users... Of course it helps if OSC (which the user doesn't necessarily have to know the technicalities and details of) works out of the box in Pd.
If you could just display an svg in a Pd patch, you could simply send me your patch and svg and I could take a look at a working example of your tape piece.
Ditto. Someone (TM) just needs to write an SVG display external :-) I could also set up qjackctl and whatever else you used to
get your unix-style implementation to work. One approach requires clicking an icon, the other makes me cringe a little when I think about just setting up the environment to view it. And I'm a Debian user comfortable with the command line and familiar with qjackctl. Take those skills away and leave only my curiousity about your approach-- the practical consequence is that I probably wouldn't be able to get up and running to experiment with it. At least without devoting more time, and that's not something many creative types have.
Again while I agree that SVG is a corner case, IMHO jack and qjackctl isn't rocket science, especially as it uses the 'connecting cables' metaphore many audio/music people are familiar and combfortable with.
Lorenzo.
-Jonathan On Tuesday, December 9, 2014 7:49 AM, Lorenzo Sutton <lorenzofsut...@gmail.com> wrote: One nice thing about the unix philosophy from a cretive person's point of view is that you do not necessarily have to use one, monolithic tool (software) to do everything. IMHO this leaves much more space to expreimentation, trial, unorthodox ways of doing things, eventually less standardised and less canned creations. This may sound a bit provocative.. but, do we really need to do 'everything' in Pd? For example for realtime scores this is rather interesting (and I must say quite appealing visually): www.iannix.org It uses OSC, which Pd supports (not sure what the 'out-of-the-box' vanilla support status is.. anyway). For a piano + electronics (a.k.a. 'tape') piece I once used Inkscape for an expressive representation of the electronic part matched to the piano part in traditional notation... I was using qjackctrl always on top to play the piece and keep track of the bars, and had to hack the SVG to import the Lilipond score :-) Bottom line. The best IMHO is that Pd is very interoperable at various levels, so JACK audio, midi, OSC, FUDI, TCP, [your favouritestandard here]. Then obviously this doesn't _exclude_ the fact that (usable) data structures are nice :-) My two cents. Lorenzo. On 04/12/2014 10:35, Julian Brooks wrote: > There is a fairly long-standing tradition of graphic scores made, > post-copmosition, of electronic music - standard practice in > Electroacoustic tuition for example. > > Yet there still isn't much around that makes the auditory/visual > connection explicit (Xenakis' UPIC and its derivatives being one of > the classic examples). > > For those interested in notational aspects and approaches within > electronic music just the idea itself of data structures is hugely > stimulating - you could even go so far to state that it's somewhat of > a 'holy grail'. > > I'm interested in data structures precisely because they don't work so > well - it's a worthwhile problem. The now well-worn, almost clichéd > story that DS's were one of the major original impetuses for Pd's > existence, and 20 years later they're still a work in progress, I > think shows that this shit ain't easy. > > Hans' DS composition from a few years back has travelled far and wide > (it's in one of the classic recent books on graphic scores - on the > front cover even!) so it's a shame that there's not much else to show > for them in recent years. > > Ligeti rocks btw, proper hardcore. > > Regards, > > Julian > > On 4 December 2014 at 09:10, i go bananas <hard....@gmail.com <mailto:hard....@gmail.com> > <mailto:hard....@gmail.com <mailto:hard....@gmail.com>>> wrote: > > and how many years work would it take to do that in pd data > structures? > > On Thu, Dec 4, 2014 at 5:04 PM, Chris McCormick > <ch...@mccormick.cx <mailto:ch...@mccormick.cx> <mailto:ch...@mccormick.cx <mailto:ch...@mccormick.cx>>> wrote: > > https://www.youtube.com/watch?v=71hNl_skTZQ > -- > http://mccormick.cx/ > > _______________________________________________ > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > > _______________________________________________ > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
