[PD] Artikulation - datastructures

Jonathan Wilkes jancsika at yahoo.com
Wed Dec 10 00:16:47 CET 2014 

On 12/09/2014 04:40 PM, Lorenzo Sutton wrote:
> 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.

Compare however long that takes to running a patch which includes the 
score in it.  In the that case it would take me a total of about 30 
seconds to download a patch and get it running it in Pd.  In that time, 
I would not have to install any other software, or run or set up a 
different audio server than what I'm using at the moment.  I just 
navigate to the file and double-click it (or open it in a terminal, 
which takes about the same time).

The time saved adds up very quickly, especially if you consider cases 
where a user wants to look at demos of some design patterns in order to 
figure out how they might complete a task.  Think about browsing 10 demo 
patches which show how to connect audio output to Gem visualizations.  
Compare that to browsing 10 demos, each of which pair a Pd patch with 
some other framework for doing visualization.

>
>>
>> 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 :-)

In Pd-l2ork, I already have drawing commands based off the SVG-spec.  I 
have a demo that shows some simple notation imported from Lilypond.  For 
more complex scores it might be better to just render the entire SVG-- I 
haven't written that feature yet, but it will be easy to implement once 
we port to Qt.

>
> 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.

It's not rocket-science, but it is time and effort and added complexity 
for the user.  If a user can get even a modicum of the functionality 
they need without _manually_ setting up IPC, they certainly will (and 
should).

The unix concept is a decent tradeoff only if you can devote adequate 
time and effort to learning system plumbing.  That makes sense for 
sysadmins, who have to learn those things anyway, but not for most 
creative types.  (At least as it's currently implemented.)

-Jonathan

>
> Lorenzo.
>
>>
>> -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>
>>  > <mailto: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>
>> <mailto: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>
>> <mailto: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>
>> <mailto: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 <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

More information about the Pd-list mailing list