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