Re: [PD] max for live

2009-01-30 Thread Kyle Klipowicz
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 h...@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 day5...@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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] max for live

2009-01-30 Thread Hans-Christoph Steiner


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  
h...@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 day5...@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.



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


Re: [PD] max for live

2009-01-29 Thread day five
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


Re: [PD] max for live

2009-01-29 Thread Kyle Klipowicz
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 day5...@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


Re: [PD] max for live

2009-01-29 Thread chris clepper
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 day5...@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

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


Re: [PD] max for live

2009-01-29 Thread Hans-Christoph Steiner


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


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


Re: [PD] max for live

2009-01-29 Thread
2009/1/29 Kyle Klipowicz kylek...@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 day5...@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

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


Re: [PD] max for live

2009-01-29 Thread
2009/1/30 xà freequenc...@gmail.com:
 2009/1/29 Kyle Klipowicz kylek...@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 day5...@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




-- 
rm -rf / i ens ho carreguem tot

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


Re: [PD] max for live

2009-01-29 Thread Kyle Klipowicz
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à freequenc...@gmail.com wrote:

 2009/1/29 Kyle Klipowicz kylek...@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 day5...@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




-- 
-

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


Re: [PD] max for live

2009-01-29 Thread Mathieu Bouchard

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___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] max for live

2009-01-28 Thread Hans-Christoph Steiner

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_pil...@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
 h...@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 | dam...@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


Re: [PD] max for live

2009-01-28 Thread Vincent Rioux
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_pil...@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
 h...@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 | dam...@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 - 
 

Re: [PD] max for live

2009-01-27 Thread harris_pilton
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
 h...@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 | dam...@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


Re: [PD] max for live

2009-01-21 Thread 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  
 h...@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 | dam...@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


Re: [PD] max for live

2009-01-19 Thread Jamie Bullock

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

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


Re: [PD] max for live

2009-01-19 Thread Damian Stewart
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.

-- 
damian stewart | skype: damiansnz | dam...@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


Re: [PD] max for live

2009-01-19 Thread hard off
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?
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] max for live

2009-01-19 Thread Kyle Klipowicz
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@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


Re: [PD] max for live

2009-01-19 Thread Daniel Almeida
I dare say PD needs to ditch tcl/tk! SDL could be a good idea.

Daniel


--- On Mon, 1/19/09, Kyle Klipowicz kylek...@gmail.com wrote:

 From: Kyle Klipowicz kylek...@gmail.com
 Subject: Re: [PD] max for live
 To: hard off hard@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@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


  

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


Re: [PD] max for live

2009-01-19 Thread Damian Stewart
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 | dam...@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


Re: [PD] max for live

2009-01-19 Thread Daniel Almeida
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...@frey.co.nz wrote:

 From: Damian Stewart damian...@frey.co.nz
 Subject: Re: [PD] max for live
 To: in...@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 | dam...@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


Re: [PD] max for live

2009-01-19 Thread Martin Schied
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.a...@gmail.com 
 mailto:x37v.a...@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_pil...@gmx.de mailto:harris_pil...@gmx.de
 harris_pil...@gmx.de mailto:harris_pil...@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
   


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


Re: [PD] max for live

2009-01-19 Thread Hans-Christoph Steiner

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...@frey.co.nz wrote:

 From: Damian Stewart damian...@frey.co.nz
 Subject: Re: [PD] max for live
 To: in...@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 | dam...@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



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


Re: [PD] max for live

2009-01-19 Thread Hans-Christoph Steiner

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



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


Re: [PD] max for live

2009-01-19 Thread Luke Iannini
On Mon, Jan 19, 2009 at 2:49 PM, Hans-Christoph Steiner h...@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 | dam...@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


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


Re: [PD] max for live

2009-01-19 Thread Jack

Le 20 janv. 09 à 00:23, Luke Iannini a écrit :

 On Mon, Jan 19, 2009 at 2:49 PM, Hans-Christoph Steiner  
 h...@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 | dam...@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


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


Re: [PD] max for live

2009-01-18 Thread Hans-Christoph Steiner


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 atur...@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.a...@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_pil...@gmx.de harris_pil...@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



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


Re: [PD] max for live

2009-01-18 Thread hard off
 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.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] max for live

2009-01-16 Thread harris_pilton
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


Re: [PD] max for live

2009-01-16 Thread Alex
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_pil...@gmx.de harris_pil...@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


Re: [PD] max for live

2009-01-16 Thread Andrew Turley
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.a...@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_pil...@gmx.de harris_pil...@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


Re: [PD] max for live

2009-01-16 Thread Kyle Klipowicz
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 atur...@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.a...@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_pil...@gmx.de harris_pil...@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


Re: [PD] max for live

2009-01-16 Thread Matthew Logan
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.a...@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_pil...@gmx.de harris_pil...@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