I am looking for documentation about the architecture of the puredata system.
Do you know some document that explains the work of the clients and server?
Thanks,
Sergi.
There's a sketchy description in:
http://crca.ucsd.edu/~msp/Publications/icmc96.ps
Some of the details didn't come out as planned there but the client/server setup at least didn't change.
cheers M
On Mon, Jul 16, 2007 at 09:34:54PM +0200, Sergi Lario wrote:
I am looking for documentation about the architecture of the puredata system.
Do you know some document that explains the work of the clients and server?
Thanks,
Sergi.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
There's a sketchy description in:
http://crca.ucsd.edu/~msp/Publications/icmc96.ps
Some of the details didn't come out as planned there but the client/server setup at least didn't change.
It's interesting to re-read section 5 "Implementation" of this 1996 paper in the light of the "renaissance" of multiprocessor systems today. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Sure enough. Pd's design is based on assumtions made in 1996 that are starting to look dated... it might be time for someone younger than me to re-think the whole edifice :)
M
On Mon, Jul 16, 2007 at 10:49:04PM +0200, Frank Barknecht wrote:
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
There's a sketchy description in:
http://crca.ucsd.edu/~msp/Publications/icmc96.ps
Some of the details didn't come out as planned there but the client/server setup at least didn't change.
It's interesting to re-read section 5 "Implementation" of this 1996 paper in the light of the "renaissance" of multiprocessor systems today. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 2007-07-16 at 13:55 -0700, Miller Puckette wrote:
Sure enough. Pd's design is based on assumtions made in 1996 that are starting to look dated... it might be time for someone younger than me to re-think the whole edifice :)
do you want to mentor a google summer-of-code project next year ;)
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman
Hmm, maybe a good idea would be to try to grab a couple of hours during the Pd convention to talk about multiprocesing and real-time media. I'd certainly benefit from finding out what other people know about this.
On Tue, Jul 17, 2007 at 09:50:04AM +0200, Tim Blechmann wrote:
On Mon, 2007-07-16 at 13:55 -0700, Miller Puckette wrote:
Sure enough. Pd's design is based on assumtions made in 1996 that are starting to look dated... it might be time for someone younger than me to re-think the whole edifice :)
do you want to mentor a google summer-of-code project next year ;)
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
unfortunately, i won't be able to attend this ... i didn't submit a paper and thus won't be at the convention ...
would be nice to have some documentation of this session, though ...
tim
On Tue, 2007-07-17 at 09:43 -0700, Miller Puckette wrote:
Hmm, maybe a good idea would be to try to grab a couple of hours during the Pd convention to talk about multiprocesing and real-time media. I'd certainly benefit from finding out what other people know about this.
On Tue, Jul 17, 2007 at 09:50:04AM +0200, Tim Blechmann wrote:
On Mon, 2007-07-16 at 13:55 -0700, Miller Puckette wrote:
Sure enough. Pd's design is based on assumtions made in 1996 that are starting to look dated... it might be time for someone younger than me to re-think the whole edifice :)
do you want to mentor a google summer-of-code project next year ;)
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Life is really simple, but we insist on making it complicated. Confucius
Well, I'm not an organizer, but if it's feasible, perhaps we should hold development discussions as a teleconference. (I've been using vic and rat for this, which have annoying shortcomings but have been useful anyway.)
As long as we can hold the discussion somewhere where there's an audio system, vidcam and projector, I can help set things up.
cheers M
On Tue, Jul 17, 2007 at 08:34:07PM +0200, Tim Blechmann wrote:
unfortunately, i won't be able to attend this ... i didn't submit a paper and thus won't be at the convention ...
would be nice to have some documentation of this session, though ...
tim
On Tue, 2007-07-17 at 09:43 -0700, Miller Puckette wrote:
Hmm, maybe a good idea would be to try to grab a couple of hours during the Pd convention to talk about multiprocesing and real-time media. I'd certainly benefit from finding out what other people know about this.
On Tue, Jul 17, 2007 at 09:50:04AM +0200, Tim Blechmann wrote:
On Mon, 2007-07-16 at 13:55 -0700, Miller Puckette wrote:
Sure enough. Pd's design is based on assumtions made in 1996 that are starting to look dated... it might be time for someone younger than me to re-think the whole edifice :)
do you want to mentor a google summer-of-code project next year ;)
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Life is really simple, but we insist on making it complicated. Confucius
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 2007-07-17 at 15:31 -0700, Miller Puckette wrote:
Well, I'm not an organizer, but if it's feasible, perhaps we should hold development discussions as a teleconference. (I've been using vic and rat for this, which have annoying shortcomings but have been useful anyway.)
if it is going to be a video conference, i will try to join ...
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Cheat your landlord if you can and must, but do not try to shortchange the Muse. It cannot be done. You can't fake quality any more than you can fake a good meal. William S. Burroughs
On Mon, 16 Jul 2007, Frank Barknecht wrote:
Miller Puckette hat gesagt: // Miller Puckette wrote:
There's a sketchy description in: http://crca.ucsd.edu/~msp/Publications/icmc96.ps Some of the details didn't come out as planned there but the client/server setup at least didn't change.
It's interesting to re-read section 5 "Implementation" of this 1996 paper in the light of the "renaissance" of multiprocessor systems today. ;)
Yeah, it's not really a "renaissance", it's that FTS/ISPW systems were designed as elite systems for elite musicians backed by elite budgets. When Opcode and Pd and jMax appeared, it was to bring patchers to personal computers.
On personal computers, multiprocessing never caught on because the fastest thing in the medium-price range was single-processor. This only changed at the time of the introduction of the G5 and the Pentium-D processor (which I won't abbreviate to "PD"...). At that time, the impending era of multiprocessing had been announced for well over 10 years and one can only cry wolf for so long...
At about the same time as that, though, personal computers got a heavily parallel coprocessor known as a GPU. Multithread support would be quite moot if the GPU could be used with the same level of flexibility that the CPU can. I don't know enough about GPUs to tell yet, but I guess that this is one of the next things I'll have to learn.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Mon, 16 Jul 2007 20:17:29 -0400 (EDT) Mathieu Bouchard matju@artengine.ca wrote:
FTS/ISPW
What does that stand for Mathieu? Google knows all about the abbreviation but I can't find an expansion.
The wierdest member of the Max family... check out
http://crca.ucsd.edu/~msp/Publications/cmj91-fts.ps
cheers M
On Tue, Jul 17, 2007 at 04:26:42PM +0100, Andy Farnell wrote:
On Mon, 16 Jul 2007 20:17:29 -0400 (EDT) Mathieu Bouchard matju@artengine.ca wrote:
FTS/ISPW
What does that stand for Mathieu? Google knows all about the abbreviation but I can't find an expansion.
-- Use the source
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 17 Jul 2007, Andy Farnell wrote:
FTS/ISPW
What does that stand for Mathieu? Google knows all about the abbreviation but I can't find an expansion.
ISPW originally stood for "12000$ not including the computer" in which "computer" is defined as "something costing at least 6500$".
However, when I finally encountered the ISPW acronym it meant "four random letters denoting the package in which basic arithmetic objects are" (???)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
--- FTS --- Documentation
Hi I think this site-documentation could be very useful: http://ccrma.stanford.edu/guides/package/jmax/fts/index.html
--- GP-GPU for Audio --- Digression
!! General Purpose GPU for audio analysis/synthesis processing. I thought to use it a year ago for spatialization, because there were/are already some promising implementations, as this technique is tightly related to geometrical computing as in light radiosity.
Other way, for fft computations, as far as I know there's still a bottleneck caused by the limited bandwidth to the rest of the system through the AGP, PCI or PCI Express bus.
So for me there are two possibilities:
- study a method for it based on current possibilities, as in "Audio
and the Graphics Processing Unit", Sean Whalen 2005
- wait for technology to change :
(ATI eyes audio acceleration on the GPU http://arstechnica.com/news.ars/post/20060526-6932.html) http://arstechnica.com/news.ars/post/20060526-6932.html
Tommaso
On Tue, 17 Jul 2007, tommaso bianco wrote:
--- FTS --- Documentation Hi I think this site-documentation could be very useful: http://ccrma.stanford.edu/guides/package/jmax/fts/index.html
It's documentation about jMax&FTS 1.5; I've only ever used version >= 2.4 and mostly just 2.5.1. You can find version 4.1 somewhere on SourceForge, but after 2.5.1 it went berserk because the project was turned on its head and all we've got were previews of FTM under the name FTS, while compatibility was broken and some major features as well.
FTM has now been known as a library for Max/MSP.
I have some additional information about FTM but I cannot disclose it. (Even though I've never worked at IRCAM !)
So, do you find it strange that you get documentation labeled "1.5" in a package labeled... what's that package anyway? Go up one folder level and it suggests that it's 2.4.5, but I've only used 2.4.5 for mere months and spent almost three years on 2.5.1.
(Going up two folders suggests that those pages might actually come from an *early* version of PlanetCCRMA dated 2000; FTS 2.5 was only released in 2001)
Actually, the FTS 1.5 documentation might have been most of what we had back then, except for the source code...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On 17 juil. 07, at 16:26, Mathieu Bouchard wrote:
On Tue, 17 Jul 2007, tommaso bianco wrote:
--- FTS --- Documentation Hi I think this site-documentation could be very useful: http://ccrma.stanford.edu/guides/package/jmax/fts/index.html
It's documentation about jMax&FTS 1.5; I've only ever used version
= 2.4 and mostly just 2.5.1. You can find version 4.1 somewhere on
SourceForge, but after 2.5.1 it went berserk because the project
was turned on its head and all we've got were previews of FTM under
the name FTS, while compatibility was broken and some major
features as well.FTM has now been known as a library for Max/MSP.
I have some additional information about FTM but I cannot disclose it. (Even though I've never worked at IRCAM !)
How comes? NOS
So, do you find it strange that you get documentation labeled "1.5"
in a package labeled... what's that package anyway? Go up one
folder level and it suggests that it's 2.4.5, but I've only used
2.4.5 for mere months and spent almost three years on 2.5.1.(Going up two folders suggests that those pages might actually come
from an *early* version of PlanetCCRMA dated 2000; FTS 2.5 was only
released in 2001)Actually, the FTS 1.5 documentation might have been most of what we
had back then, except for the source code..._ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC
Canada_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On Tue, 17 Jul 2007, Norbert Schnell wrote:
I have some additional information about FTM but I cannot disclose it. (Even though I've never worked at IRCAM !)
How comes? NOS
Because it's already disclosed, of course. How dare you ask that question!
(forget it)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
Andy Farnell -
Frank Barknecht -
Mathieu Bouchard -
Miller Puckette -
Norbert Schnell -
Sergi Lario -
Tim Blechmann -
tommaso bianco