[PD] Artikulation - datastructures

Jonathan Wilkes jancsika at yahoo.com
Tue Dec 9 20:41:25 CET 2014


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.

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.

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.  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.
-Jonathan
     On Tuesday, December 9, 2014 7:49 AM, Lorenzo Sutton <lorenzofsutton at 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.off at gmail.com 
> <mailto:hard.off at 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
>    <chris at mccormick.cx <mailto:chris at mccormick.cx>> wrote:
>
>        https://www.youtube.com/watch?v=71hNl_skTZQ
>        --
>        http://mccormick.cx/
>
>        _______________________________________________
>        Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
>        UNSUBSCRIBE and account-management ->
>        http://lists.puredata.info/listinfo/pd-list
>
>
>
>    _______________________________________________
>    Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
>    UNSUBSCRIBE and account-management ->
>    http://lists.puredata.info/listinfo/pd-list
>
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


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


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141209/3b888199/attachment-0001.html>


More information about the Pd-list mailing list