can you elaborate on surprising?
you mean the 'look' trend over the past half decade hasnt been towards oversized/fisher-price/antialiased?
one peep at the typical web 2.0 or iphone app, or ableton live, or the feature list of DesireData should lend weight to the 'theres nothing at all surprising' look (or other parts) of max 5..
looks like a nice upgrade. but isnt that off topic?
On Mon Oct 08, 2007 at 09:53:20PM -0400, Thomas O Fredericks wrote:
http://createdigitalmusic.com/2007/10/08/first-max-5-preview-music-patching-...
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hmm, looks nice, with lots of nifty features. But I think a lot of
them would drive me nuts. Like the fact that you can move the GUI
elements around in presentation mode separately from edit mode.
.hc
On Oct 8, 2007, at 9:53 PM, Thomas O Fredericks wrote:
http://createdigitalmusic.com/2007/10/08/first-max-5-preview-music- patching-the-next-generation/ _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
these links interesting as well.
An article by Zicarelly: http://www.cycling74.com/?op=displaystory;sid=2007/9/28/105551/882
and videos showing the new max: http://www.cycling74.com/story/2007/10/5/91222/9559
Hans-Christoph Steiner(e)k dio:
Hmm, looks nice, with lots of nifty features. But I think a lot of them would drive me nuts. Like the fact that you can move the GUI elements around in presentation mode separately from edit mode.
.hc
On Oct 8, 2007, at 9:53 PM, Thomas O Fredericks wrote:
http://createdigitalmusic.com/2007/10/08/first-max-5-preview-music-patching-... _______________________________________________ PD-list@iem.at mailto:PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hans, thats the whole point of presentation mode, to separate the
patching logic from the presentation!
you can organize your gui elements in the code in places that make
sense and follow the logical flow of the patch, and then present them
in the UI however you choose.
I am so glad they finally listened to Max users screaming for PD's
keyboard shortcuts for instantiation of objects method. Will make
patching much faster for us Max users.
On Oct 9, 2007, at 2:55 PM, altern wrote:
these links interesting as well.
An article by Zicarelly: http://www.cycling74.com/?op=displaystory;sid=2007/9/28/105551/882
and videos showing the new max: http://www.cycling74.com/story/2007/10/5/91222/9559
Hans-Christoph Steiner(e)k dio:
Hmm, looks nice, with lots of nifty features. But I think a lot
of them would drive me nuts. Like the fact that you can move the GUI
elements around in presentation mode separately from edit mode..hc
On Oct 8, 2007, at 9:53 PM, Thomas O Fredericks wrote:
http://createdigitalmusic.com/2007/10/08/first-max-5-preview- music-patching-the-next-generation/ _______________________________________________ PD-list@iem.at mailto:PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
v a d e //
www.vade.info abstrakt.vade.info
I understand that they are trying to separate the interface from the
implementation. The problem with that technique is there isn't a
clear way to tell which item in presentation mode belongs to which
item in edit mode. I can see having to click back and forth
between presentation and edit modes to figure out which GUI element
is attached where. It'll only get worse with more complicated patches.
Max/Pd are graphical languages, so such things should be represented
visually, whenever possible. I don't see how the two different
positions are represented, besides the little moving fade between the
two modes.
I think the "hide patch coords" function also has similar issues, it
basically reinforces bad habits. The Pd graph-on-parent makes more
sense IMHO because it uses existing Pd mechanisms for encapsulation
and encourages patchers to modularize their programs. GOP definitely
needs work, but I think it's a better path.
On a positive note, the new file browser stuff looks really handy.
The drag-n-drop message creation looks nifty, but I am not sure how
useful it is. Maybe yes, maybe no.
.hc
On Oct 9, 2007, at 3:15 PM, vade wrote:
Hans, thats the whole point of presentation mode, to separate the
patching logic from the presentation!you can organize your gui elements in the code in places that make
sense and follow the logical flow of the patch, and then present
them in the UI however you choose.I am so glad they finally listened to Max users screaming for PD's
keyboard shortcuts for instantiation of objects method. Will make
patching much faster for us Max users.On Oct 9, 2007, at 2:55 PM, altern wrote:
these links interesting as well.
An article by Zicarelly: http://www.cycling74.com/?op=displaystory;sid=2007/9/28/105551/882
and videos showing the new max: http://www.cycling74.com/story/2007/10/5/91222/9559
Hans-Christoph Steiner(e)k dio:
Hmm, looks nice, with lots of nifty features. But I think a lot
of them would drive me nuts. Like the fact that you can move the GUI
elements around in presentation mode separately from edit mode..hc
On Oct 8, 2007, at 9:53 PM, Thomas O Fredericks wrote:
http://createdigitalmusic.com/2007/10/08/first-max-5-preview- music-patching-the-next-generation/ _______________________________________________ PD-list@iem.at mailto:PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you
can hear it, you can have it. - Dizzy Gillespie
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
v a d e //
www.vade.info abstrakt.vade.info
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
The Pd graph-on-parent makes more sense IMHO because it uses existing Pd mechanisms for encapsulation and encourages patchers to modularize their programs.
100% agreed, that is why I thought "umm... what's so special about this presentation mode?" when I saw that page. To me that should be planned into the program. If your patches are messy for performance, code cleaner, use subpatches, etc, no excuses for that as far as I see. Sends and receives for gui objects have been there since I started.. I guess I wasn't really excited about any of that stuff :) but then again maybe I misunderstand..
km
I'm a bit torn on this. I actually like the concept, but you're right, like all good things that make life easy they tend to erode discipline and structure. The patch messy and sweep it all under the rug philosophy is probably very appealing to many.
On Tue, 9 Oct 2007 21:27:47 -0400 "Kevin McCoy" km.takewithyou@gmail.com wrote:
The Pd graph-on-parent makes more sense IMHO because it uses existing Pd mechanisms for encapsulation and encourages patchers to modularize their programs.
100% agreed, that is why I thought "umm... what's so special about this presentation mode?" when I saw that page. To me that should be planned into the program. If your patches are messy for performance, code cleaner, use subpatches, etc, no excuses for that as far as I see. Sends and receives for gui objects have been there since I started.. I guess I wasn't really excited about any of that stuff :) but then again maybe I misunderstand..
km
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
I'm a bit torn on this. I actually like the concept, but you're right, like all good things that make life easy they tend to erode discipline and structure. The patch messy and sweep it all under the rug philosophy is probably very appealing to many.
My performace patches typically just have one big red Toggle for on/off and everything else under the rug. So personally I don't care for that feature, but I fear, it may encourage creating "flat" patches, instead of making people modularize stuff into abstractions and build "deep" patches. But well, if it works for them ...
Ciao
Frank Barknecht _ ______footils.org__
While I agree very much with both Kevin and Frank, quoted below, i
think this "debate" is healthy, as it would be foolish not to look
for new ideas. That many new ideas will be discarded since they rime
an awful lot with Fisher Price is another matter.
On 10/10/2007, at 3.27, Kevin McCoy wrote:
Sends and receives (...)
On 10/10/2007, at 8.47, Frank Barknecht wrote:
But well, if it works for them ...
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
I'm a bit torn on this. I actually like the concept, but you're right, like all good things that make life easy they tend to erode discipline and structure. The patch messy and sweep it all under the rug philosophy is probably very appealing to many.
My performace patches typically just have one big red Toggle for on/off and everything else under the rug.
Interesting. I like thie minimal performance GUI approach also. I am curious about your big red Toggle though - what does it do? Global audio toggle, or something more... or is that a secret ;-)
Now I think of it, why not just run -nogui, and activate the toggle from a unix pipe!
Jamie
Hallo, jamie@postlude.co.uk hat gesagt: // jamie@postlude.co.uk wrote:
Interesting. I like thie minimal performance GUI approach also. I am curious about your big red Toggle though - what does it do? Global audio toggle, or something more... or is that a secret ;-)
It's not a secret: It just sends "bang" to a receiver called $0-start. ;)
Ciao
Frank Barknecht _ ______footils.org__
The one part of presentation that I was intrigued by is the idea of
separating the interface from the implementation. I think it's
interesting to explore the idea, I just think that having the only
connection be that little fade effect when switching is not really a
strong enough connection. It would only be at all effective with a
handful of elements, more than that, I think it would become hard to
track.
.hc
On Oct 10, 2007, at 9:58 AM, Andy Farnell wrote:
I'm a bit torn on this. I actually like the concept, but you're right, like all good things that make life easy they tend to erode discipline and structure. The patch messy and sweep it all under the rug philosophy is probably very appealing to many.
On Tue, 9 Oct 2007 21:27:47 -0400 "Kevin McCoy" km.takewithyou@gmail.com wrote:
The Pd graph-on-parent makes more sense IMHO because it uses
existing Pd mechanisms for encapsulation and encourages patchers to
modularize their programs.100% agreed, that is why I thought "umm... what's so special about
this presentation mode?" when I saw that page. To me that should be
planned into the program. If your patches are messy for performance, code
cleaner, use subpatches, etc, no excuses for that as far as I see. Sends and
receives for gui objects have been there since I started.. I guess I
wasn't really excited about any of that stuff :) but then again maybe I
misunderstand..km
-- Use the source
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
Since i don't like a program to educate me, but i rather like to use a program to do things that i want, the new Max features will help with that. The pd-based vibrez gui has also always separated the patcher logic from the gui, and i'm already curious to compare the two systems. To my mind it will be increasingly hard for pd to keep up with Max, now given also partial dsp multi-kernel support and the possible linux port.
gr~~~
Hans-Christoph Steiner schrieb:
The one part of presentation that I was intrigued by is the idea of
separating the interface from the implementation. I think it's
interesting to explore the idea, I just think that having the only
connection be that little fade effect when switching is not really a
strong enough connection. It would only be at all effective with a
handful of elements, more than that, I think it would become hard to
track..hc
On Oct 10, 2007, at 9:58 AM, Andy Farnell wrote:
I'm a bit torn on this. I actually like the concept, but you're right, like all good things that make life easy they tend to erode discipline and structure. The patch messy and sweep it all under the rug philosophy is probably very appealing to many.
On Tue, 9 Oct 2007 21:27:47 -0400 "Kevin McCoy" km.takewithyou@gmail.com wrote:
The Pd graph-on-parent makes more sense IMHO because it uses
existing Pd mechanisms for encapsulation and encourages patchers to
modularize their programs.100% agreed, that is why I thought "umm... what's so special about
this presentation mode?" when I saw that page. To me that should be
planned into the program. If your patches are messy for performance, code
cleaner, use subpatches, etc, no excuses for that as far as I see. Sends and
receives for gui objects have been there since I started.. I guess I
wasn't really excited about any of that stuff :) but then again maybe I
misunderstand..km
-- Use the source
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
Since i don't like a program to educate me, but i rather like to use a program to do things that i want, the new Max features will help with that. The pd-based vibrez gui has also always separated the patcher logic from the gui, and i'm already curious to compare the two systems. To my mind it will be increasingly hard for pd to keep up with Max, now given also partial dsp multi-kernel support and the possible linux port.
May be, but then, Max almost always was in advance of Pd as far as issues like usability are concerned, and still Pd was popular. Probably the new Max will make some people change their minds again, but in general I believe, both Pd and Max can coexist quite well and even learn from each other. And Max will never beat Pd's price.
Ciao
Frank Barknecht _ ______footils.org__
I just saw a preview of pd-extended's new help menu!!! it will include a direct link to the #dataflow irc chat... (besides pdpedia.org). marius.
Frank Barknecht wrote:
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
Since i don't like a program to educate me, but i rather like to use a program to do things that i want, the new Max features will help with that. The pd-based vibrez gui has also always separated the patcher logic from the gui, and i'm already curious to compare the two systems. To my mind it will be increasingly hard for pd to keep up with Max, now given also partial dsp multi-kernel support and the possible linux port.
May be, but then, Max almost always was in advance of Pd as far as issues like usability are concerned, and still Pd was popular. Probably the new Max will make some people change their minds again, but in general I believe, both Pd and Max can coexist quite well and even learn from each other. And Max will never beat Pd's price.
Ciao
Hehe, yeah, try the latest nightly build, either 0.40 or 0.39:
http://autobuild.puredata.info/auto-build/2007-10-11/
I am interested to hear if it works on Windows and GNU/Linux.
.hc
On Oct 11, 2007, at 10:25 AM, marius schebella wrote:
I just saw a preview of pd-extended's new help menu!!! it will include a direct link to the #dataflow irc chat... (besides pdpedia.org). marius.
Frank Barknecht wrote:
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
Since i don't like a program to educate me, but i rather like to
use a program to do things that i want, the new Max features will help
with that. The pd-based vibrez gui has also always separated the patcher
logic from the gui, and i'm already curious to compare the two systems. To my mind it will be increasingly hard for pd to keep up with
Max, now given also partial dsp multi-kernel support and the possible
linux port.May be, but then, Max almost always was in advance of Pd as far as issues like usability are concerned, and still Pd was popular. Probably the new Max will make some people change their minds again, but in general I believe, both Pd and Max can coexist quite well and even learn from each other. And Max will never beat Pd's price.
Ciao
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith
Hans-Christoph Steiner skrev:
Hehe, yeah, try the latest nightly build, either 0.40 or 0.39:
http://autobuild.puredata.info/auto-build/2007-10-11/
I am interested to hear if it works on Windows and GNU/Linux.
.hc
On WinXP Latest autobuild
The Links to firefox are working. IRC opens (mIRC?) but
- Connecting to \irc.freenode.net\dataflow (6667)
- Unable to resolve server
Connecting manually to dataflow works OK
mvh/Stef
On Oct 11, 2007, at 5:51 PM, Steffen Leve Poulsen wrote:
Hans-Christoph Steiner skrev:
Hehe, yeah, try the latest nightly build, either 0.40 or 0.39: http://autobuild.puredata.info/auto-build/2007-10-11/ I am interested to hear if it works on Windows and GNU/Linux. .hc
On WinXP Latest autobuild
The Links to firefox are working. IRC opens (mIRC?) but
- Connecting to \irc.freenode.net\dataflow (6667)
- Unable to resolve server
Connecting manually to dataflow works OK
mvh/Stef
Hmm, it looks like Pd is converting // to \ on Windows, but funny
that it works fine with http://. Can you open using the IRC URL from
the command line somehow?
irc://irc.freenode.net/dataflow
Could you file a bug report?
http://puredata.org/dev/bugtracker
Thanks,
.hc
There is no way to peace, peace is the way. -A.J. Muste
Hans-Christoph Steiner skrev:
On Oct 11, 2007, at 5:51 PM, Steffen Leve Poulsen wrote:
Hans-Christoph Steiner skrev:
Hehe, yeah, try the latest nightly build, either 0.40 or 0.39: http://autobuild.puredata.info/auto-build/2007-10-11/ I am interested to hear if it works on Windows and GNU/Linux. .hc
On WinXP Latest autobuild
The Links to firefox are working. IRC opens (mIRC?) but
- Connecting to \irc.freenode.net\dataflow (6667)
- Unable to resolve server
Connecting manually to dataflow works OK
I'mean. opened mIRC manually and connected
mvh/Stef
Hmm, it looks like Pd is converting // to \ on Windows,
yes
but funny that
it works fine with http://.
yes, strange
Can you open using the IRC URL from the
command line somehow?
irc://irc.freenode.net/dataflow
Yes, from Run-> No, from cmd.exe
Could you file a bug report?
Done
Mvh/Stef
On Thu, 11 Oct 2007, Frank Barknecht wrote:
May be, but then, Max almost always was in advance of Pd as far as issues like usability are concerned, and still Pd was popular. Probably the new Max will make some people change their minds again, but in general I believe, both Pd and Max can coexist quite well and even learn from each other. And Max will never beat Pd's price.
oh, pd has its price too :) just another kind of price...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On 10/11/07, Thomas Grill gr@grrrr.org wrote:
Frank Barknecht schrieb:
And Max will never beat Pd's price.
I'm quite sure this is wrong, given the time i for one invested in implementing certain kernel features, fixing bugs and providing workarounds.
On the other hand, two of us beat c74 to just about every feature for high performance graphics by years including changes in architecture.
On Oct 11, 2007, at 10:38 AM, Thomas Grill wrote:
Frank Barknecht schrieb:
And Max will never beat Pd's price.
I'm quite sure this is wrong, given the time i for one invested in implementing certain kernel features, fixing bugs and providing
workarounds.greetings, Thomas
Max does not run on embedded systems, PDAs, or iPods. I just worked
on a project where a 15 year Max veteran hired me to setup PDa for an
installation involving 550 embedded systems. I know other longtime
Max users who are learning Pd for this very reason. And that's Pd 0.37!
.hc
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
On Oct 11, 2007, at 8:55 AM, Frank Barknecht wrote:
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
Since i don't like a program to educate me, but i rather like to
use a program to do things that i want, the new Max features will help
with that. The pd-based vibrez gui has also always separated the patcher
logic from the gui, and i'm already curious to compare the two systems. To my mind it will be increasingly hard for pd to keep up with
Max, now given also partial dsp multi-kernel support and the possible linux
port.May be, but then, Max almost always was in advance of Pd as far as issues like usability are concerned, and still Pd was popular. Probably the new Max will make some people change their minds again, but in general I believe, both Pd and Max can coexist quite well and even learn from each other. And Max will never beat Pd's price.
Keep in mind the new Max is not at all available yet. Only in the
forms of demo videos. There is a lot of work to do between making it
work enough to make cool demo videos, and making something that
actually works. jMax is a great example of that.
As for "keeping up" with Max, I don't think many Pd people are
interested in doing that. Max seems to be going more and more the
route of becoming an application rather than a programming
environment, like Reactor or Quartz Composer. Pd is going the
opposite direction, IMHO, and this is a lot more interesting to me.
.hc
Ciao
Frank Barknecht _
______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
All information should be free. - the hacker ethic
I don't understand people complaining about additional features. you don't have to use it, if you don't want. but for other people it makes sense to layout their interface independently from their code. design is so important for a graphical user interface! I heard this so often "I can't share my patch, because only I know, how to use it". patches without a user interface for the run-mode are not sharable. I am not talking about patches with only an on/off button... pd is very limited in that regards and I really would wish pd would make more improvement into that direction. marius.
Kevin McCoy wrote:
The Pd graph-on-parent makes more sense IMHO because it uses existing Pd mechanisms for encapsulation and encourages patchers to modularize their programs.
100% agreed, that is why I thought "umm... what's so special about this presentation mode?" when I saw that page. To me that should be planned into the program. If your patches are messy for performance, code cleaner, use subpatches, etc, no excuses for that as far as I see. Sends and receives for gui objects have been there since I started.. I guess I wasn't really excited about any of that stuff :) but then again maybe I misunderstand..
km
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I prefer PD with a small GUI, it's better for CPU and GPU.
Jack
Le 10 oct. 07 à 16:07, marius schebella a écrit :
I don't understand people complaining about additional features. you don't have to use it, if you don't want. but for other people it makes sense to layout their interface independently from their code. design is so important for a graphical user interface! I heard this so often "I can't share my patch, because only I know,
how to use it". patches without a user interface for the run-mode are not sharable. I am not talking about patches with only an on/off button... pd is very limited in that regards and I really would wish pd would
make more improvement into that direction. marius.Kevin McCoy wrote:
The Pd graph-on-parent makes more sense IMHO because it uses
existing Pd mechanisms for encapsulation and encourages patchers to
modularize their programs.100% agreed, that is why I thought "umm... what's so special about
this presentation mode?" when I saw that page. To me that should be
planned into the program. If your patches are messy for performance, code
cleaner, use subpatches, etc, no excuses for that as far as I see. Sends and
receives for gui objects have been there since I started.. I guess I
wasn't really excited about any of that stuff :) but then again maybe I
misunderstand..km
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Am 10.10.2007 um 12:24 schrieb Jack:
I prefer PD with a small GUI, it's better for CPU and GPU.
Jack
i wonder why people do things in pd like
$ reducing the number of sliders, toggles and bangs to a minimum, or
$ running two instances of pd for the gui, or writing their gui
themselves in python, or
$ using -nogui
when its so efficient for CPU and GPU ... or was your comment ironic?
m.
Hello,
Max Neupert a écrit :
Am 10.10.2007 um 12:24 schrieb Jack:
I prefer PD with a small GUI, it's better for CPU and GPU.
Jack
i wonder why people do things in pd like $ reducing the number of sliders, toggles and bangs to a minimum, or $ running two instances of pd for the gui, or writing their gui
themselves in python, or $ using -nogui when its so efficient for CPU and GPU ... or was your comment ironic?m.
Personaly, both of those situations makes patches good looking and efficient.
Reducing the number of iem GUI is primordial, not only for gaining cpu process, but for gaining visibility, one interface patch could control several sets of similar abstractions, similar by the fact they use the same kinds of paremeter settings. Using two instance of pd is interesting, because it would be possible to use pd in a cluster like environment, with several computers, or even with one sigle computer, e.g. for Gem patches, one pd instance for the 'client interface', and the other for the 'rendering server'. -nogui could be used for one of the two instances... And extension interfaces made with tkinter, php-gtk, tcl-tk or anything else, could add features to the interface as well as replacing it. I wanted to make a project like this since some time ago, and it's called 'Mediale' now, here is how it looked like last year:
http://megalego.free.fr/pd/rastaplayxp.JPG
The principle is about having a standard sized interface for each kind of pd patch, that could be created interactively following the project done with the application.
The illustrated exemple from the upside link shows four different kinds of patches, the first one is for playing audio files like a sampler, the second one is for recording sounds, the third one is for controlling VST instruments, and the fourth is for controlling Gem objects.
Each different interfaces are created/destructed dynamically and would share the same interface patch for controlling the sound output, talking with a main sequencer, talking with another network computer ..., they would share also the same libraries, and library interfaces (color picker, sound libraries, image libraries, etc...).
And one another interface abstraction would control the creation/destruction.
This is not really another kind of netpd, because this is not really for sharing a creation through network, or this is not a sequencer only, but this could integrate netpd patches, also this could live into pd-extended box in the long term.
I wanted to add my two cents about this because I think the project is worth a try even if I don't really have time actually to complete a fully working version, and maybe some other people on the list has already made a project like that.
Thanks for attention.
On Wed, 2007-10-10 at 18:24 +0200, Jack wrote:
I prefer PD with a small GUI, it's better for CPU and GPU.
since when does pd-gui affect gpu? and what would be bad about using a most of the time just unused gpu power for a gui? i noticed, that cpu based guis in many linux audio programms are the main reason, why i think they are much more inferior to many windows programs (or probably osx programs). getting a cpu peak each time a scrollbar is touched, is just awkward and nothing more.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Dear Santa-Claus,
you have regaled to my neighbor a new release of max. You know, I'm a bad kid and use linux, but in last time I try to be better person. Ok, bad kid can't have a very stable software is a nature law but could I to have a new PD. That is my list of new derired features:
-A gui as desiredata, good for clearity. Is the hell of bad kid in white and black? I know, bad kids dont use colors and pretty features...but in my deep I have a good heart -Best suport for open formats. Why Gem dont record the wingem directly in a video file? -What about flac (open format)? -A serious suport for ("free") external plugins of audio like ladspa and dssi. My oncle csound already use it. -A layer (sintheziser, manuals, pdpedia, examples,...) focused for artists. Some dsp designer are really bad musicians and video-artist...is too law of nature :D ...
I'd like to write a long list, but I know, bad kid often dont achieve good goals. Ok if this letter is too much for a kid like me, I admit a new kernel, like all years :(
2007/10/10, Roman Haefeli reduzierer@yahoo.de:
On Wed, 2007-10-10 at 18:24 +0200, Jack wrote:
I prefer PD with a small GUI, it's better for CPU and GPU.
since when does pd-gui affect gpu? and what would be bad about using a most of the time just unused gpu power for a gui? i noticed, that cpu based guis in many linux audio programms are the main reason, why i think they are much more inferior to many windows programs (or probably osx programs). getting a cpu peak each time a scrollbar is touched, is just awkward and nothing more.
roman
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 10 Oct 2007, Vircy Parker wrote:
-A gui as desiredata, good for clearity. Is the hell of bad kid in white and black?
I'm not thinking so much about colours. I don't think that it has much to do with clarity. Perhaps it has to do with encouraging people to see the clarity in something. Clarity is an acquired skill and taste. The more you can interpret patterns and intents and interactions in your patches, the more clarity is about "deep" properties of a patch rather than colours and such; but superficial things keep some importance all along.
Anyway, DesireData is again on hold since PdConvention. The big issue is still bugs, and I needed a break. I have to change my process in order to get less frustrated and more continuously working (being pissed off by bugs is still our main cause of delays). Habits are hard to change.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hello,
i wanted to say that an interface in your main patch with a lot of
bang that receive bang every 5 ms, numberbox that receive number
every 5 ms is not good for CPU and GPU (or i'm wrong ?). Concerning
the last release of Max, i think also this not good (antialiasing,
zoom step by step moving, etc). Now i think the file browser
interesting.
Jack
Le 10 oct. 07 à 20:34, Roman Haefeli a écrit :
On Wed, 2007-10-10 at 18:24 +0200, Jack wrote:
I prefer PD with a small GUI, it's better for CPU and GPU.
since when does pd-gui affect gpu? and what would be bad about using a most of the time just unused gpu power for a gui? i noticed, that cpu based guis in many linux audio programms are the main reason, why i think they are much more inferior to many windows programs (or probably osx programs). getting a cpu peak each time a scrollbar is touched, is just awkward and nothing more.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo!
Mail: http://mail.yahoo.de
On Thu, 2007-10-11 at 15:18 +0200, Jack wrote:
Hello, i wanted to say that an interface in your main patch with a lot of
bang that receive bang every 5 ms, numberbox that receive number
every 5 ms is not good for CPU and GPU (or i'm wrong ?).
afaik, in pd this affects only the cpu, not the gpu. what i was trying to say: i would love, if it would affect the gpu instead of the cpu. the gpu provides so much computing power, that is unfortunately hardly used (at least on my linux box, it's used _only_ when i am doing Gem).
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
hmm, strange, i thought that macosx use the gpu for graphics.
Jack
Le 11 oct. 07 à 19:42, Roman Haefeli a écrit :
On Thu, 2007-10-11 at 15:18 +0200, Jack wrote:
Hello, i wanted to say that an interface in your main patch with a lot of bang that receive bang every 5 ms, numberbox that receive number every 5 ms is not good for CPU and GPU (or i'm wrong ?).
afaik, in pd this affects only the cpu, not the gpu. what i was trying to say: i would love, if it would affect the gpu instead of the
cpu. the gpu provides so much computing power, that is unfortunately hardly
used (at least on my linux box, it's used _only_ when i am doing Gem).roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
It does somewhat, but not a lot. It could use it a lot more to speed
things up.
.hc
On Oct 11, 2007, at 3:11 PM, Jack wrote:
hmm, strange, i thought that macosx use the gpu for graphics.
Jack
Le 11 oct. 07 à 19:42, Roman Haefeli a écrit :
On Thu, 2007-10-11 at 15:18 +0200, Jack wrote:
Hello, i wanted to say that an interface in your main patch with a lot of bang that receive bang every 5 ms, numberbox that receive number every 5 ms is not good for CPU and GPU (or i'm wrong ?).
afaik, in pd this affects only the cpu, not the gpu. what i was
trying to say: i would love, if it would affect the gpu instead of the cpu. the gpu provides so much computing power, that is unfortunately hardly used (at least on my linux box, it's used _only_ when i am doing Gem).roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
On 10/10/2007, at 16.07, marius schebella wrote:
I don't understand people complaining about additional features. you don't have to use it, if you don't want.
Minimal or to-the-point-ness of an application can be very desirable.
To illustrate I've for the same reasons used EevilWM not Gnome/KDE/
Fluxbox.
but for other people it makes sense to layout their interface
independently from their code.
That is also doable in Pd as is with fx. send/receive or OSC. One can
even make a custom GUI in another environment and make it
communicates with a (set of) Pd patch(es).
design is so important for a graphical user interface!
Agreed.
As i see it it's the choice of the programer (ie. Pd user) how the
interface should be. There are a lot of artistic motivation in that
choice.
A programming environment should encourage people to program in a way
that not only works, but also is clearly legible to people who have
never seen that program before. This makes it much easier to reuse
and maintain code, and that leads to much less duplicated effort.
That means everyone can benefit from the faster progress.
.hc
On Oct 10, 2007, at 10:07 AM, marius schebella wrote:
I don't understand people complaining about additional features.
you don't have to use it, if you don't want. but for other people
it makes sense to layout their interface independently from their
code. design is so important for a graphical user interface! I heard this so often "I can't share my patch, because only I know,
how to use it". patches without a user interface for the run-mode
are not sharable. I am not talking about patches with only an on/off button... pd is very limited in that regards and I really would wish pd would
make more improvement into that direction. marius.Kevin McCoy wrote:
The Pd graph-on-parent makes more sense IMHO because it uses
existing Pd mechanisms for encapsulation and encourages patchers to
modularize their programs.100% agreed, that is why I thought "umm... what's so special about
this presentation mode?" when I saw that page. To me that should be
planned into the program. If your patches are messy for performance, code
cleaner, use subpatches, etc, no excuses for that as far as I see. Sends and
receives for gui objects have been there since I started.. I guess I
wasn't really excited about any of that stuff :) but then again maybe I
misunderstand.. km
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Access to computers should be unlimited and total. - the hacker ethic
with the level of virtuosity you also want to demand new levels of requirements. it is not about displaying a visualization of the programming flow or readability of code, it is only about efficiency and user interaction. for other situations than performance or user interface, this feature is not necessary, I have to admit. marius.
Hans-Christoph Steiner wrote:
A programming environment should encourage people to program in a way that not only works, but also is clearly legible to people who have never seen that program before. This makes it much easier to reuse and maintain code, and that leads to much less duplicated effort. That means everyone can benefit from the faster progress.
.hc
On Oct 10, 2007, at 10:07 AM, marius schebella wrote:
I don't understand people complaining about additional features. you don't have to use it, if you don't want. but for other people it makes sense to layout their interface independently from their code. design is so important for a graphical user interface! I heard this so often "I can't share my patch, because only I know, how to use it". patches without a user interface for the run-mode are not sharable. I am not talking about patches with only an on/off button... pd is very limited in that regards and I really would wish pd would make more improvement into that direction. marius.
Kevin McCoy wrote:
The Pd graph-on-parent makes more sense IMHO because it uses existing Pd mechanisms for encapsulation and encourages patchers to modularize their programs.
100% agreed, that is why I thought "umm... what's so special about this presentation mode?" when I saw that page. To me that should be planned into the program. If your patches are messy for performance, code cleaner, use subpatches, etc, no excuses for that as far as I see. Sends and receives for gui objects have been there since I started.. I guess I wasn't really excited about any of that stuff :) but then again maybe I misunderstand.. km
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Access to computers should be unlimited and total. - the hacker ethic
On Wed, 2007-10-10 at 10:07 -0400, marius schebella wrote:
I don't understand people complaining about additional features. you don't have to use it, if you don't want. but for other people it makes sense to layout their interface independently from their code. design is so important for a graphical user interface! I heard this so often "I can't share my patch, because only I know, how to use it". patches without a user interface for the run-mode are not sharable. I am not talking about patches with only an on/off button... pd is very limited in that regards and I really would wish pd would make more improvement into that direction. marius.
have you ever seen a netpd-patch?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Wow, its rounded/bubbly vvvv !!!
I just realized the fancy shaded PD icon has open inlets, and closed outlets, which as far as I know comes from a rendering bug in tk... Not by design, or maybe I'm wrong...
Hans-Christoph Steiner wrote:
Hmm, looks nice, with lots of nifty features. But I think a lot of them would drive me nuts. Like the fact that you can move the GUI elements around in presentation mode separately from edit mode.
.hc
On Oct 8, 2007, at 9:53 PM, Thomas O Fredericks wrote:
http://createdigitalmusic.com/2007/10/08/first-max-5-preview-music-patching-... _______________________________________________ PD-list@iem.at mailto:PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
altern -
Andy Farnell -
B. Bogart -
cdr -
chris clepper -
Frank Barknecht -
Hans-Christoph Steiner -
Jack -
jamie＠postlude.co.uk -
Kevin McCoy -
marius schebella -
Mathieu Bouchard -
Max Neupert -
Patrice Colet -
Roman Haefeli -
Steffen Juul -
Steffen Leve Poulsen -
Thomas Grill -
Thomas O Fredericks -
vade -
Vircy Parker