hi guys,
i was just wondering why you guys dont do this max for live thing that
was announced? i guess there will be no way that pd will be
implemented in live like that? but maybe someone in the list has ideas
to work around that?
for the ones who dont know what i'm talking about; it's pretty much
this: ableton.com/extend
As Live is proprietary software, and they have already embedded Max, I don't see how PD could get into it... though PD can be used in parallel to Live, sending midi [and I assume audio?.. using Jack or soundflower or something?]
PD can also be used as a vst [though I've never done it, being a Linux only user, and preferring to work directly in PD]: http://crca.ucsd.edu/~jsarlo/pdvst/
Besides the inline editing [inside Live], I haven't thought of a real example that cannot be done with PD along-side of Live.. though, it is not as slick..
-Alex
On 1/16/09, harris_pilton@gmx.de harris_pilton@gmx.de wrote:
hi guys,
i was just wondering why you guys dont do this max for live thing that was announced? i guess there will be no way that pd will be implemented in live like that? but maybe someone in the list has ideas to work around that?
for the ones who dont know what i'm talking about; it's pretty much this: ableton.com/extend
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think the nicest thing about the Live/Max integration is that you can distribute patches without have to tell people to install all kinds of other software. Removing a few steps drastically lowers the threshold for getting people to try it.
andy
On Fri, Jan 16, 2009 at 8:35 AM, Alex x37v.alex@gmail.com wrote:
As Live is proprietary software, and they have already embedded Max, I don't see how PD could get into it... though PD can be used in parallel to Live, sending midi [and I assume audio?.. using Jack or soundflower or something?]
PD can also be used as a vst [though I've never done it, being a Linux only user, and preferring to work directly in PD]: http://crca.ucsd.edu/~jsarlo/pdvst/
Besides the inline editing [inside Live], I haven't thought of a real example that cannot be done with PD along-side of Live.. though, it is not as slick..
-Alex
On 1/16/09, harris_pilton@gmx.de harris_pilton@gmx.de wrote:
hi guys,
i was just wondering why you guys dont do this max for live thing that was announced? i guess there will be no way that pd will be implemented in live like that? but maybe someone in the list has ideas to work around that?
for the ones who dont know what i'm talking about; it's pretty much this: ableton.com/extend
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
Yep, I tried suggesting Pd/Live integration a year or two back on the Ableton wishlist forum. Looks like there are more Max users out there... Also, working with a company is probably easier and more reliable than a loose collective in terms of implementing business objectives.
I'm curious about Max for Live, and also how much it will cost. I do adore Live and use it daily.
~Kyle
On Fri, Jan 16, 2009 at 11:33 AM, Andrew Turley aturley@acm.org wrote:
I think the nicest thing about the Live/Max integration is that you can distribute patches without have to tell people to install all kinds of other software. Removing a few steps drastically lowers the threshold for getting people to try it.
andy
On Fri, Jan 16, 2009 at 8:35 AM, Alex x37v.alex@gmail.com wrote:
As Live is proprietary software, and they have already embedded Max, I don't see how PD could get into it... though PD can be used in parallel to Live, sending midi [and I assume audio?.. using Jack or soundflower or something?]
PD can also be used as a vst [though I've never done it, being a Linux only user, and preferring to work directly in PD]: http://crca.ucsd.edu/~jsarlo/pdvst/http://crca.ucsd.edu/%7Ejsarlo/pdvst/
Besides the inline editing [inside Live], I haven't thought of a real example that cannot be done with PD along-side of Live.. though, it is not as slick..
-Alex
On 1/16/09, harris_pilton@gmx.de harris_pilton@gmx.de wrote:
hi guys,
i was just wondering why you guys dont do this max for live thing that was announced? i guess there will be no way that pd will be implemented in live like that? but maybe someone in the list has ideas to work around that?
for the ones who dont know what i'm talking about; it's pretty much this: ableton.com/extend
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
What I'd like to see is interfaces like Live implemented in Pd. Pd
already has all of the audio tools, what it is missing is the GUI
toolkit. One of my goals with pd-devel and tkwidgets is first, to
make some good widgets, and second, to make it easier for people to
code intricate GUI widgets for Pd.
TkZinc would be a great base for such a thing, since it allows you to
run the GUI code with OpenGL.
.hc
On Jan 16, 2009, at 12:19 PM, Kyle Klipowicz wrote:
Yep, I tried suggesting Pd/Live integration a year or two back on
the Ableton wishlist forum. Looks like there are more Max users out
there... Also, working with a company is probably easier and more
reliable than a loose collective in terms of implementing business
objectives.I'm curious about Max for Live, and also how much it will cost. I do
adore Live and use it daily.~Kyle
On Fri, Jan 16, 2009 at 11:33 AM, Andrew Turley aturley@acm.org
wrote: I think the nicest thing about the Live/Max integration is that you can distribute patches without have to tell people to install all kinds of other software. Removing a few steps drastically lowers the threshold for getting people to try it.andy
On Fri, Jan 16, 2009 at 8:35 AM, Alex x37v.alex@gmail.com wrote:
As Live is proprietary software, and they have already embedded
Max, I
don't see how PD could get into it... though PD can be used in parallel to Live, sending midi [and I assume audio?.. using Jack or soundflower or something?]
PD can also be used as a vst [though I've never done it, being a
Linux
only user, and preferring to work directly in PD]: http://crca.ucsd.edu/~jsarlo/pdvst/
Besides the inline editing [inside Live], I haven't thought of a
real
example that cannot be done with PD along-side of Live.. though,
it is
not as slick..
-Alex
On 1/16/09, harris_pilton@gmx.de harris_pilton@gmx.de wrote:
hi guys,
i was just wondering why you guys dont do this max for live
thing that
was announced? i guess there will be no way that pd will be implemented in live like that? but maybe someone in the list has
ideas
to work around that?
for the ones who dont know what i'm talking about; it's pretty
much
this: ableton.com/extend
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
What I'd like to see is interfaces like Live implemented in Pd. Pd already has all of the audio tools, what it is missing is the GUI toolkit. One of my goals with pd-devel and tkwidgets is first, to make some good widgets, and second, to make it easier for people to code intricate GUI widgets for Pd.
TkZinc would be a great base for such a thing, since it allows you to run the GUI code with OpenGL.
please let us know how we can support these efforts. because improving pd's gui capabilities would be a real bonus.
Hans-Christoph Steiner wrote:
What I'd like to see is interfaces like Live implemented in Pd. Pd already has all of the audio tools, what it is missing is the GUI toolkit. One of my goals with pd-devel and tkwidgets is first, to make some good widgets, and second, to make it easier for people to code intricate GUI widgets for Pd.
TkZinc would be a great base for such a thing, since it allows you to run the GUI code with OpenGL.
.hc
that's been a goal of mine forever; the problem is just finding the time to sit down and do it.
imo the success of Live is due to two things: 1. the sound warping engine; 2. the loop-oriented interface, emphasising loops, specifically programmable envelope loops, to a very deep level, which make experimenting with beatmatched (or quarter-beat-matched, or 1/9th or 1/11th-beat-matched) phase relationships extremely easy.
would widgets and whatnots be subject to the same clunky slowness of other pd gui objects? or is this something that might be improved too?
That's the elephant in the room isn't it?
Live is most valuable to me because it is very cpu-friendly considering the amount of tasks being done at once in such a rich visual environment. Pd on the other hand is very slow...the equivalent of maybe 2 or 3 live devices will shoot my cpu up to 75% easily.
Of course, this is because Live devices are optimized in C++. Also, the GUI is rendered by graphing bitmap primitives onto the screen...I'm pretty sure that Pd does something different/more cpu intensive using tcl/tk.
I'm all for the effort though! I just think that Pd will need some major face lifts to get it to the usability that Live offers.
~Kyle
On Mon, Jan 19, 2009 at 6:57 AM, hard off hard.off@gmail.com wrote:
would widgets and whatnots be subject to the same clunky slowness of other pd gui objects? or is this something that might be improved too?
I dare say PD needs to ditch tcl/tk! SDL could be a good idea.
Daniel
--- On Mon, 1/19/09, Kyle Klipowicz kyleklip@gmail.com wrote:
From: Kyle Klipowicz kyleklip@gmail.com Subject: Re: [PD] max for live To: "hard off" hard.off@gmail.com Cc: pd-list@iem.at Date: Monday, January 19, 2009, 1:37 PM That's the elephant in the room isn't it?
Live is most valuable to me because it is very cpu-friendly considering the amount of tasks being done at once in such a rich visual environment. Pd on the other hand is very slow...the equivalent of maybe 2 or 3 live devices will shoot my cpu up to 75% easily.
Of course, this is because Live devices are optimized in C++. Also, the GUI is rendered by graphing bitmap primitives onto the screen...I'm pretty sure that Pd does something different/more cpu intensive using tcl/tk.
I'm all for the effort though! I just think that Pd will need some major face lifts to get it to the usability that Live offers.
~Kyle
On Mon, Jan 19, 2009 at 6:57 AM, hard off hard.off@gmail.com wrote:
would widgets and whatnots be subject to the same
clunky slowness of other
pd gui objects? or is this something that might be
improved too?
--
http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Daniel Almeida wrote:
I dare say PD needs to ditch tcl/tk! SDL could be a good idea.
Daniel
yeah that's what i said about two years ago...
the problem is, at the moment tcl/tk is embedded quite deeply into Pd itself. this is a focus of the current pd-dev effort: trying to clear this up. tcl/tk in itself isn't _necessarily_ slow, it's just that the way Pd is using it is not at all optimised (for example, as Hans-Christoph and i discovered once, when you click-drag to move an element in a graphical table, not just the element you moved but _the entire table_ is redrawn, each time).
Would it be possible to clean this up so we could have a client/server architecture making it possible to have different clients for different platforms?
Daniel
--- On Mon, 1/19/09, Damian Stewart damian.ml@frey.co.nz wrote:
From: Damian Stewart damian.ml@frey.co.nz Subject: Re: [PD] max for live To: int86@yahoo.com Cc: pd-list@iem.at Date: Monday, January 19, 2009, 3:21 PM Daniel Almeida wrote:
I dare say PD needs to ditch tcl/tk! SDL could be a
good idea.
Daniel
yeah that's what i said about two years ago...
the problem is, at the moment tcl/tk is embedded quite deeply into Pd itself. this is a focus of the current pd-dev effort: trying to clear this up. tcl/tk in itself isn't _necessarily_ slow, it's just that the way Pd is using it is not at all optimised (for example, as Hans-Christoph and i discovered once, when you click-drag to move an element in a graphical table, not just the element you moved but _the entire table_ is redrawn, each time).
-- damian stewart | skype: damiansnz | damian@frey.co.nz frey | live art with machines | http://www.frey.co.nz
Sure its possible, someone just needs to do it. That was one of the
ideas of DesireData. I would like to see that project continue to be
developed, or something like it, if anyone wants to push the envelope.
.hc
On Jan 19, 2009, at 10:12 AM, Daniel Almeida wrote:
Would it be possible to clean this up so we could have a client/ server architecture making it possible to have different clients for
different platforms?Daniel
--- On Mon, 1/19/09, Damian Stewart damian.ml@frey.co.nz wrote:
From: Damian Stewart damian.ml@frey.co.nz Subject: Re: [PD] max for live To: int86@yahoo.com Cc: pd-list@iem.at Date: Monday, January 19, 2009, 3:21 PM Daniel Almeida wrote:
I dare say PD needs to ditch tcl/tk! SDL could be a
good idea.
Daniel
yeah that's what i said about two years ago...
the problem is, at the moment tcl/tk is embedded quite deeply into Pd itself. this is a focus of the current pd-dev effort: trying to clear this up. tcl/tk in itself isn't _necessarily_ slow, it's just that the way Pd is using it is not at all optimised (for example, as Hans-Christoph and i discovered once, when you click-drag to move an element in a graphical table, not just the element you moved but _the entire table_ is redrawn, each time).
-- damian stewart | skype: damiansnz | damian@frey.co.nz frey | live art with machines | http://www.frey.co.nz
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
'You people have such restrictive dress for women,’ she said, hobbling
away in three inch heels and panty hose to finish out another pink-
collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
On Jan 19, 2009, at 9:21 AM, Damian Stewart wrote:
Daniel Almeida wrote:
I dare say PD needs to ditch tcl/tk! SDL could be a good idea.
Daniel
yeah that's what i said about two years ago...
the problem is, at the moment tcl/tk is embedded quite deeply into Pd itself. this is a focus of the current pd-dev effort: trying to
clear this up. tcl/tk in itself isn't _necessarily_ slow, it's just that the
way Pd is using it is not at all optimised (for example, as Hans-Christoph and i discovered once, when you click-drag to move an element in a graphical table, not just the element you moved but _the entire table_ is
redrawn, each time).-- damian stewart | skype: damiansnz | damian@frey.co.nz frey | live art with machines | http://www.frey.co.nz
It's slight worse, even. The entire table is deleted and re-created
on each change, not even just redrawn. That said, I am guessing the C+
- code on the GPU (Live) will always be quite a bit faster than Tcl/Tk
on the CPU. One of the ways that Live is able to make things fast is
by ignoring the native widgets on each platform and coding their own.
Tcl/Tk is the best GUI toolkit I've seen for making native-feeling
apps while writing cross-platform code.
If Live is really just blasting bitmaps to the screen, that is
something that Tcl/Tk can easily do. But I am not sure that it would
be the fastest way to implement GUI widgets.
If someone wants to help this situation, I think the best thing to do
would be to create some GUI objects using TkZinc. Then we'll have Tcl/
Tk on the GPU and that should make things quite a bit faster.
.hc
There is no way to peace, peace is the way. -A.J. Muste
On Mon, Jan 19, 2009 at 2:49 PM, Hans-Christoph Steiner hans@eds.org wrote:
On Jan 19, 2009, at 9:21 AM, Damian Stewart wrote:
Daniel Almeida wrote:
I dare say PD needs to ditch tcl/tk! SDL could be a good idea.
Daniel
yeah that's what i said about two years ago...
the problem is, at the moment tcl/tk is embedded quite deeply into Pd itself. this is a focus of the current pd-dev effort: trying to clear this up. tcl/tk in itself isn't _necessarily_ slow, it's just that the way Pd is using it is not at all optimised (for example, as Hans-Christoph and i discovered once, when you click-drag to move an element in a graphical table, not just the element you moved but _the entire table_ is redrawn, each time).
-- damian stewart | skype: damiansnz | damian@frey.co.nz frey | live art with machines | http://www.frey.co.nz
It's slight worse, even. The entire table is deleted and re-created on each change, not even just redrawn. That said, I am guessing the C+
- code on the GPU (Live) will always be quite a bit faster than Tcl/Tk
on the CPU. One of the ways that Live is able to make things fast is by ignoring the native widgets on each platform and coding their own. Tcl/Tk is the best GUI toolkit I've seen for making native-feeling apps while writing cross-platform code.
If Live is really just blasting bitmaps to the screen, that is something that Tcl/Tk can easily do. But I am not sure that it would be the fastest way to implement GUI widgets.
If someone wants to help this situation, I think the best thing to do would be to create some GUI objects using TkZinc. Then we'll have Tcl/ Tk on the GPU and that should make things quite a bit faster.
Wow, hadn't heard of TkZinc. That looks incredible. Another cloud for my Pd heaven : ). As I've been writing, I'd really love to create GUIs entirely with Data Structures - I'm not sure how much of a performance hit that causes but the opportunities for customization are much richer when it's turtles all the way down (where turtles = Pd). Is TkZinc feasible for replacing the whole GUI? It seems to support all the platforms Pd does.
Best Luke
.hc
There is no way to peace, peace is the way. -A.J. Muste
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 20 janv. 09 à 00:23, Luke Iannini a écrit :
On Mon, Jan 19, 2009 at 2:49 PM, Hans-Christoph Steiner
hans@eds.org wrote:On Jan 19, 2009, at 9:21 AM, Damian Stewart wrote:
Daniel Almeida wrote:
I dare say PD needs to ditch tcl/tk! SDL could be a good idea.
Daniel
yeah that's what i said about two years ago...
the problem is, at the moment tcl/tk is embedded quite deeply
into Pd itself. this is a focus of the current pd-dev effort: trying to clear this up. tcl/tk in itself isn't _necessarily_ slow, it's just that the way Pd is using it is not at all optimised (for example, as Hans-Christoph
and i discovered once, when you click-drag to move an element in a
graphical table, not just the element you moved but _the entire table_ is redrawn, each time).-- damian stewart | skype: damiansnz | damian@frey.co.nz frey | live art with machines | http://www.frey.co.nz
It's slight worse, even. The entire table is deleted and re-created on each change, not even just redrawn. That said, I am guessing
the C+
- code on the GPU (Live) will always be quite a bit faster than
Tcl/Tk on the CPU. One of the ways that Live is able to make things fast is by ignoring the native widgets on each platform and coding their own. Tcl/Tk is the best GUI toolkit I've seen for making native-feeling apps while writing cross-platform code.
If Live is really just blasting bitmaps to the screen, that is something that Tcl/Tk can easily do. But I am not sure that it would be the fastest way to implement GUI widgets.
If someone wants to help this situation, I think the best thing to do would be to create some GUI objects using TkZinc. Then we'll have
Tcl/ Tk on the GPU and that should make things quite a bit faster.Wow, hadn't heard of TkZinc. That looks incredible. Another cloud for my Pd heaven : ). As I've been writing, I'd really love to create GUIs entirely with Data Structures - I'm not sure how much of a performance hit that causes but the opportunities for customization are much richer when it's turtles all the way down (where turtles = Pd). Is TkZinc feasible for replacing the whole GUI? It seems to support all the platforms Pd does.
Best Luke
I can't launch TkZinc on my PPC Mac. I have download it from : http://www.tkzinc.org/downlog.php?file=Tkzinc-3.3.4.dmg How does it work ? :) ++
Jack
.hc
There is no way to peace, peace is the way. -A.J. Muste
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
On Jan 19, 2009, at 6:23 PM, Luke Iannini wrote:
On Mon, Jan 19, 2009 at 2:49 PM, Hans-Christoph Steiner
hans@eds.org wrote:On Jan 19, 2009, at 9:21 AM, Damian Stewart wrote:
Daniel Almeida wrote:
I dare say PD needs to ditch tcl/tk! SDL could be a good idea.
Daniel
yeah that's what i said about two years ago...
the problem is, at the moment tcl/tk is embedded quite deeply into
Pd itself. this is a focus of the current pd-dev effort: trying to clear this up. tcl/tk in itself isn't _necessarily_ slow, it's just that the way Pd is using it is not at all optimised (for example, as Hans-Christoph
and i discovered once, when you click-drag to move an element in a
graphical table, not just the element you moved but _the entire table_ is redrawn, each time).-- damian stewart | skype: damiansnz | damian@frey.co.nz frey | live art with machines | http://www.frey.co.nz
It's slight worse, even. The entire table is deleted and re-created on each change, not even just redrawn. That said, I am guessing
the C+
- code on the GPU (Live) will always be quite a bit faster than Tcl/
Tk on the CPU. One of the ways that Live is able to make things fast is by ignoring the native widgets on each platform and coding their own. Tcl/Tk is the best GUI toolkit I've seen for making native-feeling apps while writing cross-platform code.
If Live is really just blasting bitmaps to the screen, that is something that Tcl/Tk can easily do. But I am not sure that it would be the fastest way to implement GUI widgets.
If someone wants to help this situation, I think the best thing to do would be to create some GUI objects using TkZinc. Then we'll have
Tcl/ Tk on the GPU and that should make things quite a bit faster.Wow, hadn't heard of TkZinc. That looks incredible. Another cloud for my Pd heaven : ). As I've been writing, I'd really love to create GUIs entirely with Data Structures - I'm not sure how much of a performance hit that causes but the opportunities for customization are much richer when it's turtles all the way down (where turtles = Pd). Is TkZinc feasible for replacing the whole GUI? It seems to support all the platforms Pd does.
That is something to find out. It sounds promising. At least it
would be possible to write a TkZinc canvas which works like data
structures, but uses OpenGL.
.hc
Best Luke
.hc
There is no way to peace, peace is the way. -A.J. Muste
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Mistrust authority - promote decentralization. - the hacker ethic
hi list,
is somebody still aware of this. i mean like having it on the agenda/
taking care of it. i'm sorry for not doing it. as i so far dont have
experience in programming it might wouldn't be a good idea to let me
do that ;) i wasnt even able to follow the whole discussion. but there
seemed everybody seemed to match there has to been something on that
field.
i just wondered if anybody is doing anything on this. (maybe 2 people
are doing same things on different channels - i dont hope thats the
case...).
thanks for not getting me wrong in advance.
regards
Am 22.01.2009 um 02:21 schrieb Hans-Christoph Steiner:
On Jan 19, 2009, at 6:23 PM, Luke Iannini wrote:
On Mon, Jan 19, 2009 at 2:49 PM, Hans-Christoph Steiner hans@eds.org wrote:
On Jan 19, 2009, at 9:21 AM, Damian Stewart wrote:
Daniel Almeida wrote:
I dare say PD needs to ditch tcl/tk! SDL could be a good idea.
Daniel
yeah that's what i said about two years ago...
the problem is, at the moment tcl/tk is embedded quite deeply into Pd itself. this is a focus of the current pd-dev effort: trying to clear this up. tcl/tk in itself isn't _necessarily_ slow, it's just that the way Pd is using it is not at all optimised (for example, as Hans-Christoph and i discovered once, when you click-drag to move an element in a graphical table, not just the element you moved but _the entire table_ is redrawn, each time).
-- damian stewart | skype: damiansnz | damian@frey.co.nz frey | live art with machines | http://www.frey.co.nz
It's slight worse, even. The entire table is deleted and re-created on each change, not even just redrawn. That said, I am guessing the C+
- code on the GPU (Live) will always be quite a bit faster than Tcl/
Tk on the CPU. One of the ways that Live is able to make things fast
is by ignoring the native widgets on each platform and coding their
own. Tcl/Tk is the best GUI toolkit I've seen for making native-feeling apps while writing cross-platform code.If Live is really just blasting bitmaps to the screen, that is something that Tcl/Tk can easily do. But I am not sure that it
would be the fastest way to implement GUI widgets.If someone wants to help this situation, I think the best thing to
do would be to create some GUI objects using TkZinc. Then we'll have Tcl/ Tk on the GPU and that should make things quite a bit faster.Wow, hadn't heard of TkZinc. That looks incredible. Another cloud for my Pd heaven : ). As I've been writing, I'd really love to
create GUIs entirely with Data Structures - I'm not sure how much of a performance hit that causes but the opportunities for customization are much richer when it's turtles all the way down (where turtles = Pd). Is TkZinc feasible for replacing the whole GUI? It seems to support all the platforms Pd does.That is something to find out. It sounds promising. At least it would be possible to write a TkZinc canvas which works like data structures, but uses OpenGL.
.hc
Best Luke
.hc
There is no way to peace, peace is the way. -A.J. Muste
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Mistrust authority - promote decentralization. - the hacker ethic
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think hacking tkzinc for Pd is still very much wide open. I say go
for it, try it out, and report any experience you might have.
.hc
On Jan 27, 2009, at 11:52 AM, harris_pilton@gmx.de wrote:
hi list,
is somebody still aware of this. i mean like having it on the agenda/ taking care of it. i'm sorry for not doing it. as i so far dont have experience in programming it might wouldn't be a good idea to let me do that ;) i wasnt even able to follow the whole discussion. but there seemed everybody seemed to match there has to been something on that field. i just wondered if anybody is doing anything on this. (maybe 2 people are doing same things on different channels - i dont hope thats the case...).
thanks for not getting me wrong in advance.
regards
Am 22.01.2009 um 02:21 schrieb Hans-Christoph Steiner:
On Jan 19, 2009, at 6:23 PM, Luke Iannini wrote:
On Mon, Jan 19, 2009 at 2:49 PM, Hans-Christoph Steiner hans@eds.org wrote:
On Jan 19, 2009, at 9:21 AM, Damian Stewart wrote:
Daniel Almeida wrote:
I dare say PD needs to ditch tcl/tk! SDL could be a good idea.
Daniel
yeah that's what i said about two years ago...
the problem is, at the moment tcl/tk is embedded quite deeply into Pd itself. this is a focus of the current pd-dev effort: trying to clear this up. tcl/tk in itself isn't _necessarily_ slow, it's just that the way Pd is using it is not at all optimised (for example, as Hans-Christoph and i discovered once, when you click-drag to move an element in a graphical table, not just the element you moved but _the entire table_ is redrawn, each time).
-- damian stewart | skype: damiansnz | damian@frey.co.nz frey | live art with machines | http://www.frey.co.nz
It's slight worse, even. The entire table is deleted and re- created on each change, not even just redrawn. That said, I am guessing the C+
- code on the GPU (Live) will always be quite a bit faster than
Tcl/ Tk on the CPU. One of the ways that Live is able to make things fast is by ignoring the native widgets on each platform and coding their own. Tcl/Tk is the best GUI toolkit I've seen for making native-feeling apps while writing cross-platform code.
If Live is really just blasting bitmaps to the screen, that is something that Tcl/Tk can easily do. But I am not sure that it would be the fastest way to implement GUI widgets.
If someone wants to help this situation, I think the best thing to do would be to create some GUI objects using TkZinc. Then we'll have Tcl/ Tk on the GPU and that should make things quite a bit faster.
Wow, hadn't heard of TkZinc. That looks incredible. Another cloud for my Pd heaven : ). As I've been writing, I'd really love to create GUIs entirely with Data Structures - I'm not sure how much of a performance hit that causes but the opportunities for customization are much richer when it's turtles all the way down (where turtles = Pd). Is TkZinc feasible for replacing the whole GUI? It seems to support all the platforms Pd does.
That is something to find out. It sounds promising. At least it would be possible to write a TkZinc canvas which works like data structures, but uses OpenGL.
.hc
Best Luke
.hc
There is no way to peace, peace is the way. -A.J. Muste
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Mistrust authority - promote decentralization. - the hacker ethic
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
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
dear list,
I spent some time with tkzinc using the python wrapper and its pretty great...
see end of this page for a short demo of a zoomable interface (well the rest is all in french sorry) http://vincentrioux.net/projets/arn/index.html
it's a bit of a pain to compile tkzinc on osx though (but it's feasible)
the developpers of Tkzinc say that they will release another version soon (which will drop bindings to X11 and will integrate better support of bitmaps and svg) - and it might be easier to port to osx but _that is not_ their priority (apparently)
another possibility which i am investigating is using pyglet:
- very close to opengl
- it's pretty active
- really cross-platform
- does not provide with all the geometrical transformations and gui
power of tkzinc
best vincent
Hans-Christoph Steiner a écrit :
I think hacking tkzinc for Pd is still very much wide open. I say go
for it, try it out, and report any experience you might have..hc
On Jan 27, 2009, at 11:52 AM, harris_pilton@gmx.de wrote:
hi list,
is somebody still aware of this. i mean like having it on the agenda/ taking care of it. i'm sorry for not doing it. as i so far dont have experience in programming it might wouldn't be a good idea to let me do that ;) i wasnt even able to follow the whole discussion. but there seemed everybody seemed to match there has to been something on that field. i just wondered if anybody is doing anything on this. (maybe 2 people are doing same things on different channels - i dont hope thats the case...).
thanks for not getting me wrong in advance.
regards
Am 22.01.2009 um 02:21 schrieb Hans-Christoph Steiner:
On Jan 19, 2009, at 6:23 PM, Luke Iannini wrote:
On Mon, Jan 19, 2009 at 2:49 PM, Hans-Christoph Steiner hans@eds.org wrote:
On Jan 19, 2009, at 9:21 AM, Damian Stewart wrote:
Daniel Almeida wrote:
> I dare say PD needs to ditch tcl/tk! SDL could be a good idea. > > Daniel >
yeah that's what i said about two years ago...the problem is, at the moment tcl/tk is embedded quite deeply into Pd itself. this is a focus of the current pd-dev effort: trying to clear this up. tcl/tk in itself isn't _necessarily_ slow, it's just that the way Pd is using it is not at all optimised (for example, as Hans-Christoph and i discovered once, when you click-drag to move an element in a graphical table, not just the element you moved but _the entire table_ is redrawn, each time).
-- damian stewart | skype: damiansnz | damian@frey.co.nz frey | live art with machines | http://www.frey.co.nz
It's slight worse, even. The entire table is deleted and re- created on each change, not even just redrawn. That said, I am guessing the C+
- code on the GPU (Live) will always be quite a bit faster than
Tcl/ Tk on the CPU. One of the ways that Live is able to make things fast is by ignoring the native widgets on each platform and coding their own. Tcl/Tk is the best GUI toolkit I've seen for making native-feeling apps while writing cross-platform code.
If Live is really just blasting bitmaps to the screen, that is something that Tcl/Tk can easily do. But I am not sure that it would be the fastest way to implement GUI widgets.
If someone wants to help this situation, I think the best thing to do would be to create some GUI objects using TkZinc. Then we'll have Tcl/ Tk on the GPU and that should make things quite a bit faster.
Wow, hadn't heard of TkZinc. That looks incredible. Another cloud for my Pd heaven : ). As I've been writing, I'd really love to create GUIs entirely with Data Structures - I'm not sure how much of a performance hit that causes but the opportunities for customization are much richer when it's turtles all the way down (where turtles = Pd). Is TkZinc feasible for replacing the whole GUI? It seems to support all the platforms Pd does.
That is something to find out. It sounds promising. At least it would be possible to write a TkZinc canvas which works like data structures, but uses OpenGL.
.hc
Best Luke
.hc
There is no way to peace, peace is the way. -A.J. Muste
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Mistrust authority - promote decentralization. - the hacker ethic
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
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Live is garbage and so is their planned obsolescence business model... what are they at version 56 by now?
Now if they could embed jMax as a VST _then_ I'd be impressed.
./d5
Live is not garbage. Incremental improvement != planned obsolescence. Making software for a business is not a sin. You get what you pay for.
Open source is great. I appreciate everything that Pd and it's users stand for. However, trolling about a DAW when the free alternatives are 5 years back in the dust in terms of optimization, ease of use, and plain crash-resistance is just silly.
Some people prefer to make music, not software. Some people prefer to make software, not music. Some people prefer to make software AND music. Some people make great music software but horrible music. Some people make great music but crummy software.
~Kyle
On Thu, Jan 29, 2009 at 2:57 AM, day five day5ive@gmail.com wrote:
Live is garbage and so is their planned obsolescence business model... what are they at version 56 by now?
Now if they could embed jMax as a VST _then_ I'd be impressed.
./d5
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
How much have you used Ardour+Jack+Pd+soft synths? It is structured
very differently that Ableton Live, but I think that is actually quite
competitive in terms of what you can do with it. It is a different
system that requires as much learning as Live does.
You have been able to run Pd patches in tight sync with Ardour and a
multitude of soft synths for years now. You just don't have nifty
little embeddedness. So this really seems to me more a classic
example of the core innovation happening in free software, then
proprietary software taking the ideas and packaging them really
nicely, and promoting them a lot. (I am not saying this is a bad
thing).
The iPhone is the classic version of that. The App Store is nice,
you've been able to do that on Linux-based devices since the late
nineties, but mostly with a command line interface.
.hc
On Jan 29, 2009, at 11:27 AM, Kyle Klipowicz wrote:
Live is not garbage. Incremental improvement != planned
obsolescence. Making software for a business is not a sin. You get
what you pay for.Open source is great. I appreciate everything that Pd and it's users
stand for. However, trolling about a DAW when the free alternatives
are 5 years back in the dust in terms of optimization, ease of use,
and plain crash-resistance is just silly.Some people prefer to make music, not software. Some people prefer
to make software, not music. Some people prefer to make software AND
music. Some people make great music software but horrible music.
Some people make great music but crummy software.~Kyle
On Thu, Jan 29, 2009 at 2:57 AM, day five day5ive@gmail.com wrote: Live is garbage and so is their planned obsolescence business model... what are they at version 56 by now?
Now if they could embed jMax as a VST _then_ I'd be impressed.
./d5
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
kill your television
Hans~
I have not tried Ardour+Jack+Pd+soft synths yet. I tried downloading Ardour one time to show my 7th grade math/audio tech student. However, it was with my G4 PowerBook running OSX 10.4 and was very shaky. He does like me showing him Ableton though, and even a bit of Pd!
I'll give Ardour+Jack+Pd+soft synths (thanks copy/paste) a shot now that I have a newer-ish refurbished MacBook with OSX 10.5 on it. I'll probably end up tossing a Linux distro on here too, so we'll see.
I finally got a decent synch between Live and Pd using Live's external instrument/effects devices. I used SoundFlower and Apple's IAC MIDI bus, and the test was with Andy's trumpet patch and fibonnacci reverb. It got me excited about the possibilities. I'm going to try using Jack again also.
It's exciting to try these options. I don't want people to think I'm a hater!
~Kyle
On Thu, Jan 29, 2009 at 2:19 PM, Hans-Christoph Steiner hans@eds.orgwrote:
How much have you used Ardour+Jack+Pd+soft synths? It is structured very differently that Ableton Live, but I think that is actually quite competitive in terms of what you can do with it. It is a different system that requires as much learning as Live does.
You have been able to run Pd patches in tight sync with Ardour and a multitude of soft synths for years now. You just don't have nifty little embeddedness. So this really seems to me more a classic example of the core innovation happening in free software, then proprietary software taking the ideas and packaging them really nicely, and promoting them a lot. (I am not saying this is a bad thing).
The iPhone is the classic version of that. The App Store is nice, you've been able to do that on Linux-based devices since the late nineties, but mostly with a command line interface.
.hc
On Jan 29, 2009, at 11:27 AM, Kyle Klipowicz wrote:
Live is not garbage. Incremental improvement != planned obsolescence. Making software for a business is not a sin. You get what you pay for.
Open source is great. I appreciate everything that Pd and it's users stand for. However, trolling about a DAW when the free alternatives are 5 years back in the dust in terms of optimization, ease of use, and plain crash-resistance is just silly.
Some people prefer to make music, not software. Some people prefer to make software, not music. Some people prefer to make software AND music. Some people make great music software but horrible music. Some people make great music but crummy software.
~Kyle
On Thu, Jan 29, 2009 at 2:57 AM, day five day5ive@gmail.com wrote:
Live is garbage and so is their planned obsolescence business model... what are they at version 56 by now?
Now if they could embed jMax as a VST _then_ I'd be impressed.
./d5
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
kill your television
Part of the problem is that the Ardour community is not as big as the
Live community, so there aren't lots of people to ask questions or
examples to see. Lluis Carbonell taught the basics of this kind of
Ardour set up in a workshop in Gijon, Spain and I was really
impressed. I had also just downloaded Ardour and poked around and
never really knew what do with it. Seeing Lluis get a room full of
people getting this big Ardour set up going was a great demo.
.hc
On Jan 30, 2009, at 11:24 AM, Kyle Klipowicz wrote:
Hans~
I have not tried Ardour+Jack+Pd+soft synths yet. I tried downloading
Ardour one time to show my 7th grade math/audio tech student.
However, it was with my G4 PowerBook running OSX 10.4 and was very
shaky. He does like me showing him Ableton though, and even a bit of
Pd!I'll give Ardour+Jack+Pd+soft synths (thanks copy/paste) a shot now
that I have a newer-ish refurbished MacBook with OSX 10.5 on it.
I'll probably end up tossing a Linux distro on here too, so we'll see.I finally got a decent synch between Live and Pd using Live's
external instrument/effects devices. I used SoundFlower and Apple's
IAC MIDI bus, and the test was with Andy's trumpet patch and
fibonnacci reverb. It got me excited about the possibilities. I'm
going to try using Jack again also.It's exciting to try these options. I don't want people to think I'm
a hater!~Kyle
On Thu, Jan 29, 2009 at 2:19 PM, Hans-Christoph Steiner
hans@eds.org wrote:How much have you used Ardour+Jack+Pd+soft synths? It is structured
very differently that Ableton Live, but I think that is actually
quite competitive in terms of what you can do with it. It is a
different system that requires as much learning as Live does.You have been able to run Pd patches in tight sync with Ardour and a
multitude of soft synths for years now. You just don't have nifty
little embeddedness. So this really seems to me more a classic
example of the core innovation happening in free software, then
proprietary software taking the ideas and packaging them really
nicely, and promoting them a lot. (I am not saying this is a bad
thing).The iPhone is the classic version of that. The App Store is nice,
you've been able to do that on Linux-based devices since the late
nineties, but mostly with a command line interface..hc
On Jan 29, 2009, at 11:27 AM, Kyle Klipowicz wrote:
Live is not garbage. Incremental improvement != planned
obsolescence. Making software for a business is not a sin. You get
what you pay for.Open source is great. I appreciate everything that Pd and it's
users stand for. However, trolling about a DAW when the free
alternatives are 5 years back in the dust in terms of optimization,
ease of use, and plain crash-resistance is just silly.Some people prefer to make music, not software. Some people prefer
to make software, not music. Some people prefer to make software
AND music. Some people make great music software but horrible
music. Some people make great music but crummy software.~Kyle
On Thu, Jan 29, 2009 at 2:57 AM, day five day5ive@gmail.com wrote: Live is garbage and so is their planned obsolescence business
model... what are they at version 56 by now?Now if they could embed jMax as a VST _then_ I'd be impressed.
./d5
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
kill your television--
http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
2009/1/29 Kyle Klipowicz kyleklip@gmail.com:
Live is not garbage. Incremental improvement != planned obsolescence. Making software for a business is not a sin. You get what you pay for.
Open source is great. I appreciate everything that Pd and it's users stand for. However, trolling about a DAW when the free alternatives are 5 years back in the dust in terms of optimization, ease of use, and plain crash-resistance is just silly.
Some people prefer to make music, not software. Some people prefer to make software, not music. Some people prefer to make software AND music. Some people make great music software but horrible music. Some people make great music but crummy software.
and maybe some people make great music with great software...do you guys???????
salut xà!
~Kyle
On Thu, Jan 29, 2009 at 2:57 AM, day five day5ive@gmail.com wrote:
Live is garbage and so is their planned obsolescence business model... what are they at version 56 by now?
Now if they could embed jMax as a VST _then_ I'd be impressed.
./d5
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2009/1/30 xà freequencies@gmail.com:
2009/1/29 Kyle Klipowicz kyleklip@gmail.com:
Live is not garbage. Incremental improvement != planned obsolescence. Making software for a business is not a sin. You get what you pay for.
Open source is great. I appreciate everything that Pd and it's users stand for. However, trolling about a DAW when the free alternatives are 5 years back in the dust in terms of optimization, ease of use, and plain crash-resistance is just silly.
Some people prefer to make music, not software. Some people prefer to make software, not music. Some people prefer to make software AND music. Some people make great music software but horrible music. Some people make great music but crummy software.
better description:
and maybe some people make great music with great software...do you (((((want/desire))))) , guys???????
salut xà!
~Kyle
On Thu, Jan 29, 2009 at 2:57 AM, day five day5ive@gmail.com wrote:
Live is garbage and so is their planned obsolescence business model... what are they at version 56 by now?
Now if they could embed jMax as a VST _then_ I'd be impressed.
./d5
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- rm -rf / i ens ho carreguem tot....
Of course! I forgot to mention that combination. There are a lot of wonderfully talented musician/programmers who equally amaze me with their programming and performing skills.
I didn't mean to make it seem otherwise!
~Kyle
On Thu, Jan 29, 2009 at 6:07 PM, xà freequencies@gmail.com wrote:
2009/1/29 Kyle Klipowicz kyleklip@gmail.com:
Live is not garbage. Incremental improvement != planned obsolescence.
Making
software for a business is not a sin. You get what you pay for.
Open source is great. I appreciate everything that Pd and it's users
stand
for. However, trolling about a DAW when the free alternatives are 5 years back in the dust in terms of optimization, ease of use, and plain crash-resistance is just silly.
Some people prefer to make music, not software. Some people prefer to
make
software, not music. Some people prefer to make software AND music. Some people make great music software but horrible music. Some people make
great
music but crummy software.
and maybe some people make great music with great software...do you guys???????
salut xà!
~Kyle
On Thu, Jan 29, 2009 at 2:57 AM, day five day5ive@gmail.com wrote:
Live is garbage and so is their planned obsolescence business model... what are they at version 56 by now?
Now if they could embed jMax as a VST _then_ I'd be impressed.
./d5
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- rm -rf / i ens ho carreguem tot....
As a former jMax developer (vDSP with Christian Klippel) I can say that it embodied planned obsolescent crap software. I don't use Live, but it doesn't appear anywhere near the mismanaged mess that jMax was.
On Thu, Jan 29, 2009 at 2:57 AM, day five day5ive@gmail.com wrote:
Live is garbage and so is their planned obsolescence business model... what are they at version 56 by now?
Now if they could embed jMax as a VST _then_ I'd be impressed.
./d5
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 29 Jan 2009, chris clepper wrote:
As a former jMax developer (vDSP with Christian Klippel) I can say that it embodied planned obsolescent crap software. I don't use Live, but it doesn't appear anywhere near the mismanaged mess that jMax was.
Don't bother replying to whatever Dave Akbari says about jMax. He's just pulling your leg.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
What is the development status on PdVST?
Has anybody tried putting a later version of Pd (from later than 2004) in there? I just wanted to check to see if anyone has updated it without breaking it.
On Fri, Jan 16, 2009 at 8:35 AM, Alex x37v.alex@gmail.com wrote:
As Live is proprietary software, and they have already embedded Max, I don't see how PD could get into it... though PD can be used in parallel to Live, sending midi [and I assume audio?.. using Jack or soundflower or something?]
PD can also be used as a vst [though I've never done it, being a Linux only user, and preferring to work directly in PD]: http://crca.ucsd.edu/~jsarlo/pdvst/
Besides the inline editing [inside Live], I haven't thought of a real example that cannot be done with PD along-side of Live.. though, it is not as slick..
-Alex
On 1/16/09, harris_pilton@gmx.de harris_pilton@gmx.de wrote:
hi guys,
i was just wondering why you guys dont do this max for live thing that was announced? i guess there will be no way that pd will be implemented in live like that? but maybe someone in the list has ideas to work around that?
for the ones who dont know what i'm talking about; it's pretty much this: ableton.com/extend
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
Hi,
Matthew Logan wrote:
Has anybody tried putting a later version of Pd (from later than 2004) in there?
I don't remember which versions I used, but when trying the newest extended release version approx. one year ago it crashed on creation of the vst plugin in my host sequencer. I later used jack for Windows and midi-ox instead which worked quite well.
Martin
I just wanted to check to see if anyone has updated it without breaking it.
On Fri, Jan 16, 2009 at 8:35 AM, Alex <x37v.alex@gmail.com mailto:x37v.alex@gmail.com> wrote:
As Live is proprietary software, and they have already embedded Max, I don't see how PD could get into it... though PD can be used in parallel to Live, sending midi [and I assume audio?.. using Jack or soundflower or something?] PD can also be used as a vst [though I've never done it, being a Linux only user, and preferring to work directly in PD]: http://crca.ucsd.edu/~jsarlo/pdvst/ <http://crca.ucsd.edu/%7Ejsarlo/pdvst/> Besides the inline editing [inside Live], I haven't thought of a real example that cannot be done with PD along-side of Live.. though, it is not as slick.. -Alex On 1/16/09, harris_pilton@gmx.de <mailto:harris_pilton@gmx.de> <harris_pilton@gmx.de <mailto:harris_pilton@gmx.de>> wrote: > hi guys, > > i was just wondering why you guys dont do this max for live thing that > was announced? i guess there will be no way that pd will be > implemented in live like that? but maybe someone in the list has ideas > to work around that? > > for the ones who dont know what i'm talking about; it's pretty much > this: ableton.com/extend <http://ableton.com/extend> > > _______________________________________________ > Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@iem.at <mailto: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
On 16 Jan 2009, at 16:35, Alex wrote:
As Live is proprietary software, and they have already embedded Max, I don't see how PD could get into it... though PD can be used in parallel to Live, sending midi [and I assume audio?.. using Jack or soundflower or something?]
PD can also be used as a vst [though I've never done it, being a Linux only user, and preferring to work directly in PD]: http://crca.ucsd.edu/~jsarlo/pdvst/
The big difference is that the relationship isn't unidirectional like
with a VST plugin. With Max for Live, Max get's a new 'device' giving
Max access to most of Live's functionality from inside Max. This is a
big plus because it means you can use Max to write sequencers for
Live, which then sends data back into Max, which is pretty powerful
stuff. At a push, you might be able to emulate this with LiveAPI (http://tr.im/a0is
) + Pd + Live , but as you say it's not as slick.
Besides the inline editing [inside Live], I haven't thought of a real example that cannot be done with PD along-side of Live.. though, it is not as slick..
Yes, and it's not just slickness it's a genuinely usability gain.
Jamie
-
Alex -
Andrew Turley -
chris clepper -
Damian Stewart -
Daniel Almeida -
day five -
Hans-Christoph Steiner -
hard off -
harris_pilton＠gmx.de -
Jack -
Jamie Bullock -
Kyle Klipowicz -
Luke Iannini -
Martin Schied -
Mathieu Bouchard -
Matthew Logan -
Vincent Rioux -
xà