20 Apr
2004
20 Apr
'04
6:45 p.m.
hi all,
since i'm about to rewrite my (pd) performace patch, i'm curious if i
should switch to supercollider ...
i heard that (on macs) supercollider computes much more efficient than
max/msp ... is that somehow compareable to linux / i686 / pd?
has anyone tried to run benchmarks with similar patches on both programs
to compare the cpu usage?
cheers...
Tim mailto:TimBlechmann@gmx.de
ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
Jack Kerouac
21 Apr
21 Apr
9:48 a.m.
Hallo,
Tim Blechmann hat gesagt: // Tim Blechmann wrote:
since i'm about to rewrite my (pd) performace
patch, i'm curious if i
should switch to supercollider ...
i heard that (on macs) supercollider computes much more efficient than
max/msp ... is that somehow compareable to linux / i686 / pd?
has anyone tried to run benchmarks with similar patches on both programs
to compare the cpu usage?
I doubt, that the dsp calculations will really be faster on SC3 than
in Pd. Pd actually can calculate things very fast and also is
optimized for realtime work. Nevertheless you know that Pd still has
problems with the GUI sometimes disturbing audio computation. This
won't happen with SC3. But it also doesn't happen when Pd is run in
"-nogui" mode.
As SC3 to my knowledge doesn't have a GUI in the Linux version, you
either will have to live without one or use something else as GUI, for
example Pd, which can control SC over OSC. See Kjetil's SC-objects for
Pd.
Generally I'd say, that Pd and Supercollider are so different, that
they cannot sensibly be compared. SC is a text based synthesis
language that will be much better at certain things than Pd, whereas
Pd offers a very hands-on approach to building software instruments
and more (and has many third-party modules for graphics and the like).
Still, learning more about SC3 is on my TODO-list as well. Let's start
on LAConf2, shall we? ;)
Ciao
--
Frank Barknecht _ ______footils.org__
10:50 a.m.
Frank Barknecht <fbar(a)footils.org> writes:
Hallo,
Tim Blechmann hat gesagt: // Tim Blechmann wrote:
> i heard that (on macs) supercollider computes much more efficient than
> max/msp ... is that somehow compareable to linux / i686 / pd?
It definitely was true on macs in the past. AFAIK James McCartney
knows the apple architecture very well it has always been able to
squeeze the most out of it. SC allowed to build more complex
processes than max/msp before running into 100% cpu usage. But the
last time I checked (in Mac OS 8.6 or 9) SC was at version 2 and Max 3.5 /MSP 1. SC was
also way more stable then.
I doubt, that the dsp calculations will really be
faster on SC3 than
in Pd. Pd actually can calculate things very fast and also is
optimized for realtime work.
My guess is that SC is probably more efficient on Macs (esp. taking
into consideration the Altivec optimisations). And possibly it is
more efficient than PD on a Mac. Just guessing... In the intel world
there possibly isn't a big difference.
Generally I'd say, that Pd and Supercollider are
so different, that
they cannot sensibly be compared. SC is a text based synthesis
language that will be much better at certain things than Pd, whereas
Pd offers a very hands-on approach to building software instruments
and more (and has many third-party modules for graphics and the like).
That's true. Howver there was a thread recently on SC mailing list
about SC having a 'better sound' compared to Max. I think some of the
points could as well apply to SC vs Pd. I _think_ the mailing has an
archive somewhere but I don't have the link handy. Overall, James
McC's comment that was very interesting was the fact that SC's
architecture allows for creating/synthesizing more complex sounds more
easily.
BTW, SC's GUI is catching up on the linux version as well.
cheers,
--
_
__ __ (_)___ Michal Seta
/ \/ \ _/^ _|
/ V |_ \ @creazone.32k.org
(___/V\___|_|___/
http://www.[creazone]|[noonereceiving].32k.org
10:58 a.m.
I doubt, that the dsp calculations will really be
faster on SC3 than
in Pd. Pd actually can calculate things very fast and also is
optimized for realtime work. Nevertheless you know that Pd still has
problems with the GUI sometimes disturbing audio computation. This
won't happen with SC3. But it also doesn't happen when Pd is run in
"-nogui" mode.
pd and sc3 have completely different architectures ... on
pd one thread
is computing everything (dsp, control messages, gui) ... and the dsp
engine is related directly to the graphical representation of the
patches...
i'm not really familiar with the way the sc3 server works, but it's
probably only computing dsp ...
As SC3 to my knowledge doesn't have a GUI in the
Linux version, you
either will have to live without one or use something else as GUI, for
example Pd, which can control SC over OSC. See Kjetil's SC-objects for
Pd.
that was my idea ... pd's gui, sc's dsp
i haven't fully understood pd's dsp engine, but i don't know if it's so
good, that dsp and gui are that connected to each other ... so if i
would rebuild my pd patch, i'll devide it into two seperate pieces, one
dsp and one gui block that run in different instances ... and if i'd do
that, why not change the dsp engine ...
Still, learning more about SC3 is on my TODO-list as
well. Let's start
on LAConf2, shall we? ;)
one of the reasons why i go there ;-)
Tim mailto:TimBlechmann@gmx.de
ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
Jack Kerouac
11:07 a.m.
Tim Blechmann <TimBlechmann(a)gmx.net> writes:
that was my idea ... pd's gui, sc's dsp
i haven't fully understood pd's dsp engine, but i don't know if it's so
good, that dsp and gui are that connected to each other ... so if i
would rebuild my pd patch, i'll devide it into two seperate pieces, one
dsp and one gui block that run in different instances ... and if i'd do
that, why not change the dsp engine ...
Tim, have you followd a bit the posts by Mathieu Bouchard on the
pd-list? He's the one who branched out the pd-dev version and called
it impd (impure data). Part of the work he's doing with it is to
sseparate the core pd engine from the GUI. So, since you're already
familiar with pd impd may be interesting to look at. I'm afraid that
right now it's a little frustrating to try to get some serious work
done with impd but Mathieu is working quite fast.
I gotta run to work right now but in the meantime you can check
#dataflow channel on irc.freenode.net and see if matju is there...
Otherwise can provide more info/links if need be later on.
--
_
__ __ (_)___ Michal Seta
/ \/ \ _/^ _|
/ V |_ \ @creazone.32k.org
(___/V\___|_|___/
http://www.[creazone]|[noonereceiving].32k.org
22 Apr
22 Apr
7:45 a.m.
Tim, have you followd a bit the posts by Mathieu
Bouchard on the
pd-list? He's the one who branched out the pd-dev version and called
it impd (impure data). Part of the work he's doing with it is to
sseparate the core pd engine from the GUI. So, since you're already
familiar with pd impd may be interesting to look at. I'm afraid that
right now it's a little frustrating to try to get some serious work
done with impd but Mathieu is working quite fast.
i'm aware of impd, well, i
know that it exists and that won't work right
now ... and that it's not sure if it will be only a branch or a second
pd, that's not really related to miller puckett's branch any more ...
well, as hans-christoph pointed out, pd's developement is coordinated
disorganization ...
cheers...
Tim mailto:TimBlechmann@gmx.de
ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
Jack Kerouac
23 Apr
23 Apr
7:21 p.m.
Tim Blechmann <TimBlechmann(a)gmx.net> writes:
i'm aware of impd, well, i know that it exists and
that won't work right
now ... and that it's not sure if it will be only a branch or a second
pd, that's not really related to miller puckett's branch any more ...
I know what you mean. However, similar thing happened when an
independent version surfaced in CVS. There are efforts to keep things
in sync with Miller's version but a lot of interesting developments
happened thanks to that branch (notably jack support). Hopefully, if
other developers accept impd's premise and actually agree with those
features and enhancements it may evolve and improve significantly. I
know that Mathieu would appreciate some help especially when a time of
merging audio changes into impd comes. I won't hide the fact that I
like the direction impd is taking. I just hope that the audio side
will not be competely abandoned. But I just discovered recently that
it's more stable with GEM (I had random crashes when going through
examples of pmpd in pd. did not crash once in impd).
well, as hans-christoph pointed out, pd's
developement is coordinated
disorganization ...
well, I'm not sure about the 'coordinated' part. However, pd has come
a long way and I'm thankful for that.
--
_
__ __ (_)___ Michal Seta
/ \/ \ _/^ _|
/ V |_ \ @creazone.32k.org
(___/V\___|_|___/
http://www.[creazone]|[noonereceiving].32k.org
24 Apr
24 Apr
6:40 a.m.
merging audio changes into impd comes. I won't
hide the fact that I
like the direction impd is taking. I just hope that the audio side
will not be competely abandoned. But I just discovered recently that
it's more stable with GEM (I had random crashes when going through
examples of pmpd in pd. did not crash once in impd).
i had a look at impd,
yesterday ... i haven't been able to use it (work
in progress), but i'll definitely have a look at it again, when it's
done ... and i'm willing to try to merge the dsp changes between the
devel and the impd branch ...
what i criticize is not _what_ mathieu is doing, but that there is no
roadmap where pd should go. mathieu set up his own roadmap, but probably
his impd and millers future stable releases will go to different
directions ...
there is too little communication between the pd developers ...
well, I'm not sure about the 'coordinated'
part. However, pd has come
a long way and I'm thankful for that.
no one is introducing changes that will
harm any changes by the other
developers ...
cheers...
Tim mailto:TimBlechmann@gmx.de
ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
Jack Kerouac
3:55 p.m.
Tim Blechmann <TimBlechmann(a)gmx.net> writes:
i had a look at impd, yesterday ... i haven't been
able to use it (work
in progress), but i'll definitely have a look at it again, when it's
done ...
It may take a while :)
and i'm willing to try to merge the dsp changes
between the
devel and the impd branch ...
cool :) May I tell Mathieu about it? :)
what i criticize is not _what_ mathieu is doing, but
that there is no
roadmap where pd should go. mathieu set up his own roadmap, but probably
his impd and millers future stable releases will go to different
directions ...
there is too little communication between the pd developers ...
I agree and it seems that this was the case from the beginning (I
started using pd at around version .29). But there seems to be a lot of
uncertainty about directions among the developers, although I have not
really seen any vigurous disagreements... perhaps it's just lack of
any clear future goals? I know I seem to be taking
impd's side but I'm not really hooked on it yet. I would just give
mathieu a point for the initiative and action in moving towards the
realisation.
Ok, I think we've move sufficiently off-topic here... Sorry.
--
_
__ __ (_)___ Michal Seta
/ \/ \ _/^ _|
/ V |_ \ @creazone.32k.org
(___/V\___|_|___/
http://www.[creazone]|[noonereceiving].32k.org
25 Apr
25 Apr
12:40 p.m.
I agree and it seems that this was the case from the
beginning (I
started using pd at around version .29). But there seems to be a lot
of uncertainty about directions among the developers, although I have
not really seen any vigurous disagreements... perhaps it's just lack
of any clear future goals? I know I seem to be taking
impd's side but I'm not really hooked on it yet. I would just give
mathieu a point for the initiative and action in moving towards the
realisation.
i understand your point ... maybe the pd developers should meet and
discuss in order to set up a roadmap ... well, the lad conference would
be a place for something like that, but afaik the main pd developers
(miller, guenter, mathieu) won't be there ... it's unlikely that all
these people will ever be on one place at the same time, but maybe it's
possible to invite them to an online meeting...
(maybe more a discussion for the pd lists than the lau list ;-)
cheers...
Tim mailto:TimBlechmann@gmx.de
ICQ: 96771783
--
The only people for me are the mad ones, the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn,
burn, like fabulous yellow roman candles exploding like spiders across
the stars and in the middle you see the blue centerlight pop and
everybody goes "Awww!"
Jack Kerouac
21 Apr
21 Apr
11:21 a.m.
Frank Barknecht wrote:
As SC3 to my knowledge doesn't have a GUI in the
Linux version, you
either will have to live without one or use something else as GUI, for
example Pd, which can control SC over OSC. See Kjetil's SC-objects for
Pd.
As Michael pointed out, SC3/Linux certainly does have GUI objects.
Stefan Kersten has been handling that part of the port, and his work is
coming along nicely. I've been adapting some of the numerous examples
from the SC docs, some things have worked out pretty well. Bear in mind
that Stefan refers to the GUI components as alpha-stage software at the
present time.
Generally I'd say, that Pd and Supercollider are so
different, that
they cannot sensibly be compared. SC is a text based synthesis
language that will be much better at certain things than Pd, whereas
Pd offers a very hands-on approach to building software instruments
and more (and has many third-party modules for graphics and the like).
I would also add that SC3 (by virtue of its language-orientation?) is
maybe better at more deterministic music composition. I'd suggest that
Pd is perhaps better at synthesis, thanks to its collection of ugens,
but I've yet to explore the more than 250 (!) ugens of SC3. IMO, SC3 is
just waiting for Linux audio people to find it. If Stefan's GUI parts
keep improving we'll soon have a very respectable SC3 for Linux.
Docs for both SC3 and Pd are most admirable.
Still, learning more about SC3 is on my TODO-list as
well. Let's start
on LAConf2, shall we? ;)
Stefan will be giving a presentation there on SC3 for Linux. See you
then ! :)
Btw, I recently learned that the author of the Q programming language
has entered the "Let's write an interface for SC3" contest. His q-synth
(not the same item as Qsynth) is another language interface for SC3, but
I've had no time to check it out. I've also not tried using Pd to
control SC3, and I'd love to see an example patch demonstrating how it
could be done.
Gruss,
dp
12:14 p.m.
Dave Phillips wrote:
IMO, SC3 is
just waiting for Linux audio people to find it. If Stefan's GUI parts
keep improving we'll soon have a very respectable SC3 for Linux.
I consider myself "Linux audio people" and I'm just waiting for some
reasonable docu of the beat. The only really useful stuff was your
tutorial, but that stopped just when the fun was about to begin.
Seems that what docu is there is either for sc2 or doesn't relate to linux.
I'm currently using csound, but for several reasons I'm very interrested
in switching to (or at least trying out) SC3.
If I overlooked anything please let me know. And maybe you (who seems to
have found The Way) could also suggest a path through the docu towards
understanding SC3/linux???
--
peace, love & harmony
Atte
http://www.atte.dk
12:28 p.m.
Hi Atte:
The juice is in the RTF help files run from within emacs. Almost all
examples are playable (i.e., evaluated) from within the help system, and
many of them demonstrate useful musical capabilities of SC3 (looping,
triggering, MIDI control, etc.). However, I certainly agree that a
thorough SC3/Linux tutorial is desirable (and I agree that my tutorial
only peeks at SC3). The wiki can be helpful, but it isn't always in step
with current SC3 development. The sc-users mail list is also a good
place to ask questions.
HTH,
dp
Atte André Jensen wrote:
Dave Phillips wrote:
IMO, SC3 is just waiting for Linux audio people
to find it. If
Stefan's GUI parts keep improving we'll soon have a very respectable
SC3 for Linux.
I consider myself "Linux audio people" and I'm just waiting for some
reasonable docu of the beat. The only really useful stuff was your
tutorial, but that stopped just when the fun was about to begin.
Seems that what docu is there is either for sc2 or doesn't relate to
linux.
I'm currently using csound, but for several reasons I'm very
interrested in switching to (or at least trying out) SC3.
If I overlooked anything please let me know. And maybe you (who seems
to have found The Way) could also suggest a path through the docu
towards understanding SC3/linux???
22 Apr
22 Apr
6:19 a.m.
Dave Phillips wrote:
Hi Atte:
The juice is in the RTF help files run from within emacs. Almost all
examples are playable (i.e., evaluated) from within the help system, and
many of them demonstrate useful musical capabilities of SC3 (looping,
triggering, MIDI control, etc.). However, I certainly agree that a
thorough SC3/Linux tutorial is desirable (and I agree that my tutorial
only peeks at SC3). The wiki can be helpful, but it isn't always in step
with current SC3 development. The sc-users mail list is also a good
place to ask questions.
Thanks for the pointers, I guess the main thing I payed to little
attention to was the RTFManual (pun intented). I'll try to devote a
whole day saturday to getting further into SC3. You'll probl. hear more
confused questions from me on sc-users...
--
peace, love & harmony
Atte
http://www.atte.dk
11:01 a.m.
Atte André Jensen wrote:
... I guess the main thing I payed to little attention
to was the
RTFManual (pun intented). I'll try to devote a whole day saturday to
getting further into SC3. You'll probl. hear more confused questions
from me on sc-users...
Stefan Kersten is The Man when it comes to SC3/Linux questions, so he'll
probably be answering your queries. But I'll be glad to help as I'm able...
Best,
dp
7591
days inactive
7596
days old
linux-audio-user@lists.linuxaudio.org
14 comments
5 participants
participants (5)
-
Atte André Jensen -
Dave Phillips -
Frank Barknecht -
Michal Seta -
Tim Blechmann