Sound quality in MAX....
Hi
through the years I have heard (and still hear) people complaining
that the sound quality of the MaxMSP engine is "poor"
I don't know how "poor" it is, and this is not the subject of this
post; but some of those people did point that the "sound quality" of
CSound or Reaktor is way better (or Super Collider) - and even if I
don't have any personal opinion on this subject, some of the people
saying this seem to know what they are talking about (but not all of
them !!)
Now my question is:
IF the sound quality (or DSP engine, or whatever) of, say, CSound or
Reaktor is better, WHEN I use Reaktor as a plug-in or CSound via the
csound~ object in MAX, do I have "max quality" or "Reaktor/CSound
quality" ??
Obviously a plug-in/other software used in max will at some point
have its sound carried by MSP (be it for simple routing - out volume,
pan, or maybe simply the DAC....
___as said - don't know how true it is, and IF it was if it still is
- and maybe in Max 5 it's different (I did not switched to max5):
But, since I am willing to try other software (CSound is very
tempting) I am interested to know - and one of the lessons on C74
site describes integration of other sofwares into max: using them
this way seems very interesting.
many thanks
best
kasper
--
Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com
this is something that immediately leapt out at me when I first
played around with the SuperCollider examples
how amazing the sound quality on all their patches was compared to
Max/MSP
never got to doing a direct A/B comparison but it would be good to
know why this is...
I posted something to this list about this years ago but never got a
response
anyone?
On Aug 20, 2008, at 1:06 PM, Kasper T Toeplitz wrote:
> Hi
>
> through the years I have heard (and still hear) people complaining
> that the sound quality of the MaxMSP engine is "poor"
>
> I don't know how "poor" it is, and this is not the subject of this
> post; but some of those people did point that the "sound quality"
> of CSound or Reaktor is way better (or Super Collider) - and even
> if I don't have any personal opinion on this subject, some of the
> people saying this seem to know what they are talking about (but
> not all of them !!)
>
> Now my question is:
>
> IF the sound quality (or DSP engine, or whatever) of, say, CSound
> or Reaktor is better, WHEN I use Reaktor as a plug-in or CSound via
> the csound~ object in MAX, do I have "max quality" or "Reaktor/
> CSound quality" ??
>
> Obviously a plug-in/other software used in max will at some point
> have its sound carried by MSP (be it for simple routing - out
> volume, pan, or maybe simply the DAC....
>
> ___as said - don't know how true it is, and IF it was if it still
> is - and maybe in Max 5 it's different (I did not switched to
> max5): But, since I am willing to try other software (CSound is
> very tempting) I am interested to know - and one of the lessons on
> C74 site describes integration of other sofwares into max: using
> them this way seems very interesting.
>
> many thanks
>
> best
>
> kasper
> --
> Kasper T. Toeplitz
> noise, composition, bass, computer
> http://www.sleazeArt.com
>
> http://www.myspace.com/sleazeart
>
That's a good question that I would like to know the answer to also.
I don't know about the math but just by listening I am of the opinion
that supercollider and csound are superior to max in terms of sound
quality. For me quality means clarity and freshness. You can hear
this difference if you compare a simple oscilator in supercollider or
csound with one in max. Same with filters. However, a lot of this
depends on what it is that you're trying to do and how you code it.
Best
Peiman
On 20 Aug 2008, at 21:06, Kasper T Toeplitz wrote:
> Hi
>
> through the years I have heard (and still hear) people complaining
> that the sound quality of the MaxMSP engine is "poor"
>
> I don't know how "poor" it is, and this is not the subject of this
> post; but some of those people did point that the "sound quality"
> of CSound or Reaktor is way better (or Super Collider) - and even
> if I don't have any personal opinion on this subject, some of the
> people saying this seem to know what they are talking about (but
> not all of them !!)
>
> Now my question is:
>
> IF the sound quality (or DSP engine, or whatever) of, say, CSound
> or Reaktor is better, WHEN I use Reaktor as a plug-in or CSound via
> the csound~ object in MAX, do I have "max quality" or "Reaktor/
> CSound quality" ??
>
> Obviously a plug-in/other software used in max will at some point
> have its sound carried by MSP (be it for simple routing - out
> volume, pan, or maybe simply the DAC....
>
> ___as said - don't know how true it is, and IF it was if it still
> is - and maybe in Max 5 it's different (I did not switched to
> max5): But, since I am willing to try other software (CSound is
> very tempting) I am interested to know - and one of the lessons on
> C74 site describes integration of other sofwares into max: using
> them this way seems very interesting.
>
> many thanks
>
> best
>
> kasper
> --
> Kasper T. Toeplitz
> noise, composition, bass, computer
> http://www.sleazeArt.com
>
> http://www.myspace.com/sleazeart
>
Hi,
All the best
--
Alessandro Fogar
2008/8/20 Kim Cascone :
> this is something that immediately leapt out at me when I first played
> around with the SuperCollider examples
> how amazing the sound quality on all their patches was compared to Max/MSP
> never got to doing a direct A/B comparison but it would be good to know why
> this is...
> I posted something to this list about this years ago but never got a
> response
> anyone?
>
>
> On Aug 20, 2008, at 1:06 PM, Kasper T Toeplitz wrote:
>
>> Hi
>>
>> through the years I have heard (and still hear) people complaining that
>> the sound quality of the MaxMSP engine is "poor"
>>
>> I don't know how "poor" it is, and this is not the subject of this post;
>> but some of those people did point that the "sound quality" of CSound or
>> Reaktor is way better (or Super Collider) - and even if I don't have any
>> personal opinion on this subject, some of the people saying this seem to
>> know what they are talking about (but not all of them !!)
>>
>> Now my question is:
>>
>> IF the sound quality (or DSP engine, or whatever) of, say, CSound or
>> Reaktor is better, WHEN I use Reaktor as a plug-in or CSound via the csound~
>> object in MAX, do I have "max quality" or "Reaktor/CSound quality" ??
>>
>> Obviously a plug-in/other software used in max will at some point have its
>> sound carried by MSP (be it for simple routing - out volume, pan, or maybe
>> simply the DAC....
>>
>> ___as said - don't know how true it is, and IF it was if it still is - and
>> maybe in Max 5 it's different (I did not switched to max5): But, since I am
>> willing to try other software (CSound is very tempting) I am interested to
>> know - and one of the lessons on C74 site describes integration of other
>> sofwares into max: using them this way seems very interesting.
>>
>> many thanks
>>
>> best
>>
>> kasper
>> --
>> Kasper T. Toeplitz
>> noise, composition, bass, computer
>> http://www.sleazeArt.com
>>
>> http://www.myspace.com/sleazeart
>>
>
>
without drawing harsch consequences, I can say through my experiences that
even a soundfile playback would sound different in MaxMSP than Logic. And
why not in Csound or Supercollider. This difference will be more obvious
and clear in a quality listening environment and with high end audio
interface/loudspeakers.
sinan
> Hi
>
> through the years I have heard (and still hear) people complaining
> that the sound quality of the MaxMSP engine is "poor"
>
> I don't know how "poor" it is, and this is not the subject of this
> post; but some of those people did point that the "sound quality" of
> CSound or Reaktor is way better (or Super Collider) - and even if I
> don't have any personal opinion on this subject, some of the people
> saying this seem to know what they are talking about (but not all of
> them !!)
>
> Now my question is:
>
> IF the sound quality (or DSP engine, or whatever) of, say, CSound or
> Reaktor is better, WHEN I use Reaktor as a plug-in or CSound via the
> csound~ object in MAX, do I have "max quality" or "Reaktor/CSound
> quality" ??
>
> Obviously a plug-in/other software used in max will at some point
> have its sound carried by MSP (be it for simple routing - out volume,
> pan, or maybe simply the DAC....
>
> ___as said - don't know how true it is, and IF it was if it still is
> - and maybe in Max 5 it's different (I did not switched to max5):
> But, since I am willing to try other software (CSound is very
> tempting) I am interested to know - and one of the lessons on C74
> site describes integration of other sofwares into max: using them
> this way seems very interesting.
>
> many thanks
>
> best
>
> kasper
> --
> Kasper T. Toeplitz
> noise, composition, bass, computer
> http://www.sleazeArt.com
>
> http://www.myspace.com/sleazeart
>
>
Sinan Bokesoy
sinan@sonic-disorder.com
www.sonic-disorder.com
I am also under the impression that both supercollider and csound sound better.
I'd guess that it might have to do with how anti-aliasing is handled and the type of interpolation used, specifically in oscillators.
Also, a wider range of (more refined) filters is available for both supercollider and csound.
Less aliasing, better interpolation and nicer filters could explain for much of the perceived difference, but again, I'm just guessing.
@Kasper:
I think that the sound quality difference is in the DSP of supercollider and csound. Using these languages inside a bigger Max/MSP framework will give still give you their sonic benefits. Panning, fading or some minor further processing will not negate that.
I think you should look at it as using a better mic for an instrument that you then process further in Max. The better the sound quality you start with, the nicer the result. Similarly, a nicer sounding oscillator or filter will still sound nicer after further processing in Max.
BTW, I think there is very little - if any - difference in sound quality between sc/csound and max when it comes to multiplying signals (level/pan), and other basic things like playing a file from disk/ram.
Regards,
Klaas-Jan
Hi,
look also here:
All the best
--
Alessandro Fogar
2008/8/20 Alessandro Fogar :
> Hi,
>
> http://lists.create.ucsb.edu/pipermail/sc-users/2004-April/009580.html
>
> All the best
>
> --
> Alessandro Fogar
>
> http://www.fogar.it
>
> 2008/8/20 Kim Cascone :
>> this is something that immediately leapt out at me when I first played
>> around with the SuperCollider examples
>> how amazing the sound quality on all their patches was compared to Max/MSP
>> never got to doing a direct A/B comparison but it would be good to know why
>> this is...
>> I posted something to this list about this years ago but never got a
>> response
>> anyone?
>>
>>
>> On Aug 20, 2008, at 1:06 PM, Kasper T Toeplitz wrote:
>>
>>> Hi
>>>
>>> through the years I have heard (and still hear) people complaining that
>>> the sound quality of the MaxMSP engine is "poor"
>>>
>>> I don't know how "poor" it is, and this is not the subject of this post;
>>> but some of those people did point that the "sound quality" of CSound or
>>> Reaktor is way better (or Super Collider) - and even if I don't have any
>>> personal opinion on this subject, some of the people saying this seem to
>>> know what they are talking about (but not all of them !!)
>>>
>>> Now my question is:
>>>
>>> IF the sound quality (or DSP engine, or whatever) of, say, CSound or
>>> Reaktor is better, WHEN I use Reaktor as a plug-in or CSound via the csound~
>>> object in MAX, do I have "max quality" or "Reaktor/CSound quality" ??
>>>
>>> Obviously a plug-in/other software used in max will at some point have its
>>> sound carried by MSP (be it for simple routing - out volume, pan, or maybe
>>> simply the DAC....
>>>
>>> ___as said - don't know how true it is, and IF it was if it still is - and
>>> maybe in Max 5 it's different (I did not switched to max5): But, since I am
>>> willing to try other software (CSound is very tempting) I am interested to
>>> know - and one of the lessons on C74 site describes integration of other
>>> sofwares into max: using them this way seems very interesting.
>>>
>>> many thanks
>>>
>>> best
>>>
>>> kasper
>>> --
>>> Kasper T. Toeplitz
>>> noise, composition, bass, computer
>>> http://www.sleazeArt.com
>>>
>>> http://www.myspace.com/sleazeart
>>>
>>
>>
>
yeah, but the question was not IF they are different (better) but
what happens (sound-quality wise) when one is embedded in the other
(this does not apply to SC - but does to CSound)
best
kasper
>
>@Kasper:
>I think that the sound quality difference is in the DSP of
>supercollider and csound. Using these languages inside a bigger
>Max/MSP framework will give still give you their sonic benefits.
>Panning, fading or some minor further processing will not negate
>that.
>
>I think you should look at it as using a better mic for an
>instrument that you then process further in Max. The better the
>sound quality you start with, the nicer the result. Similarly, a
>nicer sounding oscillator or filter will still sound nicer after
>further processing in Max.
So it would be the question how the sound is produced ?? I mean (and
don't know about this deep programming) the way an oscillator (or a
filter) is "build".... not, say, the "transport" (handling) of
signal, the way it is transmitted to the rest of the computer, or
whatever.....
Your "mic" analogy sounds nice - actually it would not so much be the
mic than the instrument...
Anyhow, still interesting to hear reactions !
best
kasper
--
Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com
Quote: Kasper T Toeplitz wrote on Wed, 20 August 2008 23:06
----------------------------------------------------
> So it would be the question how the sound is produced ?? I mean (and
> don't know about this deep programming) the way an oscillator (or a
> filter) is "build".... not, say, the "transport" (handling) of
> signal, the way it is transmitted to the rest of the computer, or
> whatever.....
Indeed. You know how the 2up state variable filter sounds nicer than the standard svf~ in Max? Same thing. What is going on *inside* the object (the dsp) is done differently resulting in a better/different sound quality.
Both filters then output their data as 32bit float through those same patch cords..
> Your "mic" analogy sounds nice - actually it would not so much >be the mic than the instrument...
Either way. Better source, better results down the line (providing the rest is unchanged), that was my point.
I guess when speaking about filtering the mic would be the better analogy, and when speaking about oscillators the instrument makes more sense.
Also, it is hard to measure how one instrument is better than the other. With microphones things tend to be slightly less subjective... They are slightly more defined in function (and ideal characteristics).
> Anyhow, still interesting to hear reactions !
Yes, anywhoo, I'd be interested to hear other's opinions too :)
Just a word, my Csound's csd files sound better in csound than in [csound~].
Quote: Kyred wrote on Thu, 21 August 2008 00:29
----------------------------------------------------
> Just a word, my Csound's csd files sound better in csound than in [csound~].
----------------------------------------------------
interesting!
could you record to 32 bit float in both max and csound and phase align both recordings in a daw to do a null test? maybe even post the difference file? i'd be curious to hear what gremlins are there :)
ah interesting! I'm ~kinda surprised this hasn't come up before as a
thread, as I often harumph about MSP's "sound quality" in comparison
to Reaktor. like most here, I don't know much about the nitty gritty
of this, but when I route to MSP processes (via jack) from-and-to
Reaktor, things do sound "better." so I'm glad that many on this list
seem to have the same subjective bias (or AMAZING hearing) that I do.
I hope it's the latter....
Here are two factors that might make a difference between programs:
- Is internal processing in the program 32-bit or 64 bit floats? MSP is 32 bit.
- Is some kind of DC filtering, limiter or saturation applied to the signals on the way out of the program?
Most Reaktor ensembles include several effects: chorus, delay, distorsion, reverb...
So this might explain the "Reaktor" sound, partly at least. I guess you could add those to your MaxMSP patches too.
Roald Baudoux
---- Original message ----
>Date: Wed, 20 Aug 2008 19:57:59 -0400
>From: Billy Gomberg
>Subject: Re: [maxmsp] Re: Sound quality in MAX....
>
>ah interesting! I'm ~kinda surprised this hasn't come up before as a
>thread, as I often harumph about MSP's "sound quality" in comparison
>to Reaktor. like most here, I don't know much about the nitty gritty
>of this, but when I route to MSP processes (via jack) from-and-to
>Reaktor, things do sound "better." so I'm glad that many on this list
>seem to have the same subjective bias (or AMAZING hearing) that I do.
>I hope it's the latter....
>
>bg
>http://fraufraulein.com/billyframe.html
>
hi
in aswer to answers
@Derrick Giscloux:
>Just a word, my Csound's csd files sound better in csound than in [csound~].
which would mean it's not only a question of the oscillators
themselves, but also of the environement in which they run...
@Trond Lossius:
>Here are two factors that might make a difference between programs:
>
>- Is internal processing in the program 32-bit or 64 bit floats? MSP
>is 32 bit.
>- Is some kind of DC filtering, limiter or saturation applied to the
>signals on the way out of the program?
I don't know about Csound and Reaktor (on NI web page they say "This
product needs a 32-bit compatible environment to operate under 64-bit
versions of Windows XP/Vista."). But if those (CSound, reaktor) are
64, this could explain that...
@Roald Baudoux:
>Most Reaktor ensembles include several effects: chorus, delay,
>distorsion, reverb...
>
>So this might explain the "Reaktor" sound, partly at least. I guess
>you could add those to your MaxMSP patches too.
Well what I am talking about is not a question of reverb, nor of
ready-made instruments - and some of the people who told me about
this or that sonic superiority are knowledgeable enough with DSP that
I belive they are not fooled by a chorus!
******
but the final (or first) question was - when an audio-generating
program runs inside MAX (so NOT super Collider) is its
"audio-quality" dependent of Max or of itself?? How does it work?
many thanks
kasper
--
Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com
it sounds crazy, but i am convinced that the user interface/ user experience of a piece of software plays some role in how people think it sounds. For instance i immediately felt that my patches sounded somehow better when i switched to Max5.
The test would be to do some "blind" comparisons of the different apps doing the same thing to see if one could tell which was which by sound alone.
oli
"it sounds crazy, but i am convinced that the user interface/ user experience of a piece of software plays some role in how people think it sounds. "
oli
don't go there don't go there dont go there don't go there.< Considering shadow hills preamps. >
Quote: oli larkin wrote on Thu, 21 August 2008 05:24
----------------------------------------------------
> it sounds crazy, but i am convinced that the user interface/ user experience of a piece of software plays some role in how people think it sounds. For instance i immediately felt that my patches sounded somehow better when i switched to Max5.
>
> The test would be to do some "blind" comparisons of the different apps doing the same thing to see if one could tell which was which by sound alone.
>
> oli
>
>
----------------------------------------------------
Perhaps it does, but then how do you relate that to the current discussion where 'people' prefer the sound of SC or Csound (which have no GUI other than a terminal window and a text editor, at default) to Max or Reaktor.
My opinion, though, is that 'Max sounds bad' is another internet-originated meme that has no basis in reality.
>Perhaps it does, but then how do you relate that to the current discussion where 'people' prefer the sound of SC or Csound (which have no GUI other than a terminal window and a text editor, at default) to Max or Reaktor.
this is why i said user experience... my experience of supercollider is a slick cocoa app and my experience of csound ( a long time ago) was with windows notepad.
I am not saying that this is totally the reason for people claiming a difference in sound quality, but i think it is a factor that is overlooked.
oli
I think the best proposal so far was the frame-per-frame comparison
of CSound~ straight into float32 sfrecord~ vs CSound output in a
similar format...
anyone has the time to do this?
pa
Sure, I can do this. What Csound .csd to use, though?
I am very interested in knowing more about this as well.
I know many reaktor ensembles have built in filtering and
saturation that make them sound better. It would be neat
to run a test on the output of Reaktor and csound outside
Max and the output running through Max.
To do that right one would need to be able to capture the audio
before it went to the dac, to a file. You could then do a spectrum
analysis to see if they really are different. Csound and Max have
file output, Reaktor does not. Ideally it would be nice to have
an audio interface that had the option of file output.
Does any one have a setup that does this?
On Aug 20, 2008, at 3:44 PM, Klaas-Jan Govaart wrote:
>
> Quote: Kyred wrote on Thu, 21 August 2008 00:29
> ----------------------------------------------------
>> Just a word, my Csound's csd files sound better in csound than in
>> [csound~].
> ----------------------------------------------------
>
> interesting!
>
> could you record to 32 bit float in both max and csound and phase
> align both recordings in a daw to do a null test? maybe even post
> the difference file? i'd be curious to hear what gremlins are there :)
yes this would be a great test and worthy of posting...anyone with
both apps have time to do this?
ideal would be to .zip up three files:
- SC sound file 32b float
- MSP sound file 32b float
- invert->diff sound file 32b float
also using something like Risset's Bell instrument might be a good
generator since I believe it exists in Csound, Max/MSP and
Supercollider
I went ahead and used the am.csd in the Csound examples folder in both Max 5.0.4 with the latest csound~ and the csound5gui.exe in the bin folder of the Csound5 installation.
The 'csound max.wav' was recorded with sfrecord in mono/44.1/32b float and the 'csound.wav' was recorded using the csound5gui.exe built-in recorder in mono/44.1/32b float.
I've never done phase aligning/nulling before. Maybe someone else would like to try with these two files:
I compared the two using Visual Analyzer's spectrum analyzer and phase analyzer and I could not discern any differences between the two.
hi (again)
Thanks for all the answers (i did not expect that many). But now the
dicussion goes towards "is SC (or CS) better or same than max,
sound-wise", which was not my original question (and frankly if I was
able to say that this or that software sounds better - especially in
a live situation, which is the main part of my work - I would be
using it since a long time).
no, the question was " IF such-or-such software sounds "better" (or
just way different) just because of its DSP, or "audio engine", what
happens when this software is embedded in Max ? does it keep its own
"audio engine" characteristics or does "use" the Max "audio-engine"
or DSP way-of-working ?"
I know it is not a very "tech" question, but i don't even know how to
code. (be it in C or Java or....) - I just use max, used a little bit
of CSound, a minimal amount of Super Collider - and some Reaktor.
Some of you have (partly) answered this question, but most saw it as
"is SC better sounding than max ?". which was not the initial post
(beside SC does not apply here - all vst do, Csound does (via
csound~), and also chuck - never tried it - and probably some
others...)
sorry for this precision
all the best
kasper
--
Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com
my completely biased opinion is that a lot of this has to do with how easy it is to add more voices in reaktor or supercollider than it is in MSP.
Of course one can do this with the poly~ object, but it is still much simpler to tell Reaktor to have 5 voices, or to make an array of oscillators in Supercollider with phase offset for each voice.
I still think that Max has tons of advantages over reaktor when it comes to flexibility and over supercollider when it comes to usability.
Quote: RabidRaja wrote on Thu, 21 August 2008 11:21
----------------------------------------------------
> still, I would love it if, like the mxj object and the js object, someone came up with an sc object that allowed you to program supercollider within max(instantiating the object would automatically cause the localhost and internalhost servers to show up with full functionality, etc.).
>
> just a little pipe dream of mine, though, i guess...
----------------------------------------------------
You can drive SC with OSC, if you like. Not exactly the same, but handy.
mz
On Aug 21, 2008, at 10:00 AM, matt wrote:
> I compared the two using Visual Analyzer's spectrum analyzer and
> phase analyzer and I could not discern any differences between the
> two.
I used this patch, and could also not find any differences (other than
time alignment):
Chris Muir
cbm@well.com
http://www.xfade.com
Kasper --
As one who has imbedded a few 'outside' languages in max/msp, I doubt
that there is any hard-core DSP reason (with one exception) for a
given language-object to sound better in max/msp than the native
oscillators, etc. that Cycling provides. In rtcmix~ and chuck~, the
computed samples are put into a buffer that is passed back into the
msp environment for additional processing, playing, etc. I suspect
that internally all these languages are doing some kind of floating-
point sample computing, and I doubt that the differences would be
audibly significant.
I think that the main "sounds better" claims are the result from two
factors that James McC. identified in his post that was ref'd in this
thread. The first has to do with certain things (like layering
sounds, adding additional DSP, whatever) being easier to do in some
environments than in others. Designing a physical-model instrument
is easy in RTcmix or ChucK, but fairly tricky (if not almost
impossible) in 'native' max/msp. Other operations are much easier in
max/msp (coordinating with video, designing interfaces,
interactivity, etc.); and the fun part of today's happy computing
world is we get to choose what works best for a particular
situation. Max/msp's strength isn't the ease with which very
particular audio parameters can be tweaked -- although some can be
-- but why try to force it to do this when other, easier options are
available?
The other factor (the one exception I alluded to above) that James
mentioned probably does have an audible impact on the sound: rtcmix~
and chuck~ (and SC3, csound~) have much better mechanisms for
handling many control-rate operations, complex envelopes in
particular. rtcmix~ allows for the dynamic specification of control-
signal updates with several different types of signal interpolation
available. With almost every parameter of a given sound-synthesis or
DSP algorithm 'envelope-able', this does make a big difference in how
the result "sounds".
I would be somewhat surprised if there were big differences in a sine
wave, or more complex wave, produced internally by rtcmix~/chuck~/
csound~ or through in/out routing of SC3. But our perception of
'good sound' is a lot more than that. And of course I've been really
wrong about lots of stuff before...
On Aug 21, 2008, at 1:43 PM, Kasper T Toeplitz wrote:
> hi (again)
>
> Thanks for all the answers (i did not expect that many). But now
> the dicussion goes towards "is SC (or CS) better or same than max,
> sound-wise", which was not my original question (and frankly if I
> was able to say that this or that software sounds better -
> especially in a live situation, which is the main part of my work -
> I would be using it since a long time).
>
> no, the question was " IF such-or-such software sounds "better" (or
> just way different) just because of its DSP, or "audio engine",
> what happens when this software is embedded in Max ? does it keep
> its own "audio engine" characteristics or does "use" the Max "audio-
> engine" or DSP way-of-working ?"
>
> I know it is not a very "tech" question, but i don't even know how
> to code. (be it in C or Java or....) - I just use max, used a
> little bit of CSound, a minimal amount of Super Collider - and some
> Reaktor.
>
> Some of you have (partly) answered this question, but most saw it
> as "is SC better sounding than max ?". which was not the initial
> post (beside SC does not apply here - all vst do, Csound does (via
> csound~), and also chuck - never tried it - and probably some
> others...)
>
> sorry for this precision
>
> all the best
>
> kasper
> --
> Kasper T. Toeplitz
> noise, composition, bass, computer
> http://www.sleazeArt.com
>
> http://www.myspace.com/sleazeart
>
I looked into doing this, but it made a lot more sense to use OSC
from max/msp to communicate to/from the SC server. Personally, I'm
not a big fan of this model, but disentangling the code to make a
tighter-coupling between the two languages is not something I really
want to do with my life right now. The SC3 environment was designed
particularly with OSC communication in mind, so it makes sense to use
it. The tricky part comes when you want to get audio to/from SC3
from max/msp, but with a little work it's not too difficult:
On Aug 21, 2008, at 2:21 PM, raja wrote:
>
> still, I would love it if, like the mxj object and the js object,
> someone came up with an sc object that allowed you to program
> supercollider within max(instantiating the object would
> automatically cause the localhost and internalhost servers to show
> up with full functionality, etc.).
>
> just a little pipe dream of mine, though, i guess...
Derrick Giscloux schrieb:
> Just a word, my Csound's csd files sound better in csound than in [csound~].
Could you just record them digitally and do a bit by bit comparison?
(subtract and listen to the resulting noise...)
The same for Sinan, play a sound file in Max, play it in Logic, and do a
bit by bit comparison...
If there is a difference, it should be possible to find out the reason,
but I have no idea why there should be a difference...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
matt schrieb:
> Perhaps it does, but then how do you relate that to the current
> discussion where 'people' prefer the sound of SC or Csound (which
> have no GUI other than a terminal window and a text editor, at
> default) to Max or Reaktor.
If you love your own environment, you need a reason not to switch... ;-)
No, I am certain, that the tool itself affects the way you create. Try
to work with a UPIC and you'll immediately pull out a different music
than with any other tool. Maybe its just a matter of taste. Its very
hard to compare, I am not at all concerned about "sound quality" though,
I am concerned about structure, also structures within sound.
You could only compare the same things, thus the bit by bit comparison
of the same only can tell, or we start to talk about taste...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
On Aug 21, 2008, at 1:33 PM, Chris Muir wrote:
> I used this patch, and could also not find any differences (other
> than time alignment):
I spoke too soon. There are tiny differences in about half the samples
of the csound examples.
Here's a revised patch that shows the errors better. The errors are
tiny enough that I had to increase the display resolution of the
number boxes involved. Also, amplifying the differences enough to hear
them is left as an excersize to the user (be careful, a lot of gain
will be required)
-C
Chris Muir
cbm@well.com
http://www.xfade.com
I'm pretty sure that there is (or was) a clause in the SC license which prohibited its use as a library within some other programming context. A "don't make a SC object for Max" clause, if you will. Maybe that's changed, but I doubt it.
jb
Quote: Jeremy Bernstein wrote on Fri, 22 August 2008 01:09
----------------------------------------------------
> I'm pretty sure that there is (or was) a clause in the SC license which prohibited its use as a library within some other programming context. A "don't make a SC object for Max" clause, if you will. Maybe that's changed, but I doubt it.
----------------------------------------------------
These days, it's standard GPL. Skimming, I don't see anything that would preclude an object, other than a lot of hard work.
-C
Jeremy,
you are right.
James Mc Cartney talked about this saying it's impossible.
Yes, I'd like very much a similar external !
All the best
--
Alessandro Fogar
2008/8/22, Jeremy Bernstein :
>
> I'm pretty sure that there is (or was) a clause in the SC license which prohibited its use as a library within some other programming context. A "don't make a SC object for Max" clause, if you will. Maybe that's changed, but I doubt it.
>
>
> jb
>
>
On 22 Aug 2008, at 10:28, Chris Muir wrote:
>
> Quote: Jeremy Bernstein wrote on Fri, 22 August 2008 01:09
> ----------------------------------------------------
>> I'm pretty sure that there is (or was) a clause in the SC license
>> which prohibited its use as a library within some other
>> programming context. A "don't make a SC object for Max" clause, if
>> you will. Maybe that's changed, but I doubt it.
> ----------------------------------------------------
>
> These days, it's standard GPL. Skimming, I don't see anything that
> would preclude an object, other than a lot of hard work.
some time ago i asked something along these lines on the sc list and
was told that it's a no go.
obviously it's a violation against the GPL to link GPL'd code to
proprietary software (and that is what you do, when you write a max
external).
i wonder how brad garton is handling this with e.g. chuck~, since
chuck is under GPL, too.
probably nobody cares about it.
vb
As far as I understand it, and I'm not an expert, creating an external for Max is different than incorporating GPL code into a proprietary application. An external is more like a plug-in; as long as the source for the plug-in (and any changes to the incorporated GPL code) remains available, it should be ok.
jb
On 2008 Aug 22, at 6:07 AM, Jeremy Bernstein wrote:
> As far as I understand it, and I'm not an expert, creating an
> external for Max is different than incorporating GPL code into a
> proprietary application. An external is more like a plug-in; as long
> as the source for the plug-in (and any changes to the incorporated
> GPL code) remains available, it should be ok.
This is why it is not:
http://electrotap.net/blog/show/192
best,
Tim
Thanks for the clarification!
jb
This is my 'working assumption' also.
On Aug 22, 2008, at 7:07 AM, Jeremy Bernstein wrote:
>
> As far as I understand it, and I'm not an expert, creating an
> external for Max is different than incorporating GPL code into a
> proprietary application. An external is more like a plug-in; as
> long as the source for the plug-in (and any changes to the
> incorporated GPL code) remains available, it should be ok.
>
> jb
> This is my 'working assumption' also.
poor you, In the light of McCarthy's emails, all the chuck and RTcmix
lawyers will come and get you, take all your money (because you
obviously became rich with this ;-)
pa
> I spoke too soon. There are tiny differences in about half the
> samples of the csound examples.
Interesting results... Once the files are aligned (523 frames apart)
I've got some differences (+/- 0.000001). Now, would that be
significant in real-life... (this is a strange test done with an LFO)
but it shows that there is a difference in the 2 files. Maybe with 2
passes in each program, to compare them as well to see if we get such
errors, would make that test more reliable.
I presume there would be a couple of interesting tests to do, more on
the subjective side:
- simple additive synthesis w/o randomisation (Risset's bells?)
- simple subtractive synthesis
- 24-bit test file playback at unity gain
I have not got time for that, but I can maybe put a postgrad on the
case after ICMC... because I'd be happy to see the result!
pa
Quote: Chris Muir wrote on Fri, 22 August 2008 01:51
----------------------------------------------------
>
> On Aug 21, 2008, at 1:33 PM, Chris Muir wrote:
> > I used this patch, and could also not find any differences (other
> > than time alignment):
>
>
> I spoke too soon. There are tiny differences in about half the samples
> of the csound examples.
>
> Here's a revised patch that shows the errors better. The errors are
> tiny enough that I had to increase the display resolution of the
> number boxes involved. Also, amplifying the differences enough to hear
> them is left as an excersize to the user (be careful, a lot of gain
> will be required)
>
> -----------end_max5_patcher-----------
>
>
> -C
>
> Chris Muir
> cbm@well.com
> http://www.xfade.com
>
----------------------------------------------------
How do I figure out the offset needed to time-align the two samples?
I've just uploaded two more. These were done with a risset glissandi.
It's the two '*' ones...
On Aug 22, 2008, at 8:52 AM, Pierre Alexandre Tremblay wrote:
>> This is my 'working assumption' also.
>
> poor you, In the light of McCarthy's emails, all the chuck and
> RTcmix lawyers will come and get you, take all your money (because
> you obviously became rich with this ;-)
You betcha! I've already launched a lawsuit against myself regarding
RTcmix, that way I'll win no matter what the outcome. Plus it's the
American Way.
> How do I figure out the offset needed to time-align the two samples?
I just used the following patch, (cynical, it is in max, Nuendo was
not installed in our new studios...) and when I got the first 3
samples aligned, bingo! It is underdocumented, but you will figure it
out ;-)
pa
>
> No, I am certain, that the tool itself affects the way you create.
I second this. One of the great things about Max is that it
facilitates happy mishaps. It's very easy to accidentally misconnect
something, and there's a low penalty for trying things out, and this
is a big advantage over other audio programming languages which
require more explicit planning. There are always tradeoffs, of
course, but Max's connectivity to other languages certainly helps to
smooth this out.
Peter McCulloch
On Aug 22, 2008, at 4:28 AM, Timothy Place wrote:
> This is why it is not:
> http://electrotap.net/blog/show/192
Frackin' religious zealots.
-C
Chris Muir
cbm@well.com
http://www.xfade.com
On Aug 22, 2008, at 7:07 AM, matt wrote:
> How do I figure out the offset needed to time-align the two samples?
I scrub the time-aligned offset numbers to find the first sample in
both files.
-C
Chris Muir
cbm@well.com
http://www.xfade.com
Quote: Timothy Place wrote on Fri, 22 August 2008 12:28
----------------------------------------------------
> On 2008 Aug 22, at 6:07 AM, Jeremy Bernstein wrote:
>
> > As far as I understand it, and I'm not an expert, creating an
> > external for Max is different than incorporating GPL code into a
> > proprietary application. An external is more like a plug-in; as long
> > as the source for the plug-in (and any changes to the incorporated
> > GPL code) remains available, it should be ok.
>
> This is why it is not:
> http://electrotap.net/blog/show/192
>
> best,
> Tim
>
>
That's why I use the MIT license on LyonPotpourri and FFTease:
Eric
Quote: tremblap@gmail.com wrote on Fri, 22 August 2008 07:18
----------------------------------------------------
> > I spoke too soon. There are tiny differences in about half the
> > samples of the csound examples.
>
> Interesting results... Once the files are aligned (523 frames apart)
> I've got some differences (+/- 0.000001).
By default, audio data is scaled between csound~ and Csound. In MaxMSP, 0dB == 1.0. In Csound, 0dB == 32768.0 (unless the user has changed the 0dB level with the 0dbfs opcode). To bypass scaling, add the "noscale" flag to csound~'s argument list.
What's the situation here with respect to these examples? I wouldn't be entirely surprised if one or two io multiplies were creating this difference. I may be way off here, and obviously csound must be scaling the file when it outputs, but I'd be interested to know. I don't believe anything different will be happening in the audio dsp EXCEPT at the output stage (ie. transfer to max and sound file recording in both cases..)
32 bit float precision is equivalent to around 7 decimal places so as far as I can figure out 0.000001 in relation to a signal of around 1, is a error in one of the the last 2 bits of the significand (ie. dropping off the end of what can be represented) and something like -120 dB of error - for a smaller signal the error would be higher and relate to a more significant bit / bits - bear in mind the numberboxes are rounding too.... the question is not how big the error as an actual value, but how big in relation to the signal....
Quote: AlexHarker wrote on Fri, 22 August 2008 12:12
----------------------------------------------------
> Quote: tremblap@gmail.com wrote on Fri, 22 August 2008 07:18
> ----------------------------------------------------
> > > I spoke too soon. There are tiny differences in about half the
> > > samples of the csound examples.
> >
> > Interesting results... Once the files are aligned (523 frames apart)
> > I've got some differences (+/- 0.000001).
>
>
> From http://www.davixology.com/csound~_manual.html#inlets_outlets
>
> By default, audio data is scaled between csound~ and Csound. In MaxMSP, 0dB == 1.0. In Csound, 0dB == 32768.0 (unless the user has changed the 0dB level with the 0dbfs opcode). To bypass scaling, add the "noscale" flag to csound~'s argument list.
>
> What's the situation here with respect to these examples? I wouldn't be entirely surprised if one or two io multiplies were creating this difference. I may be way off here, and obviously csound must be scaling the file when it outputs, but I'd be interested to know. I don't believe anything different will be happening in the audio dsp EXCEPT at the output stage (ie. transfer to max and sound file recording in both cases..)
>
> 32 bit float precision is equivalent to around 7 decimal places so as far as I can figure out 0.000001 in relation to a signal of around 1, is a error in one of the the last 2 bits of the significand (ie. dropping off the end of what can be represented) and something like -120 dB of error - for a smaller signal the error would be higher and relate to a more significant bit / bits - bear in mind the numberboxes are rounding too.... the question is not how big the error as an actual value, but how big in relation to the signal....
----------------------------------------------------
Hi,
I don't know if this caused the differences but I'm using Csound5 Doubles (which uses 64-bit float for internal calculations) as the API in both examples.
Also, here is the .orc and .sco. I did not use the noscale argument with the csound~ external. I went right from the object to an sfrecord~ with no gain or other adjustments.
.orc
instr 1
k2 oscil 10000, 1, 1
a1 oscil 10000+k2, 120, 1
chano a1, 1
out a1
endin
.sco
f1 0 16384 10 1
; run for 30 secs
i1 0 30
On Aug 22, 2008, at 7:07 AM, matt wrote:
> I've just uploaded two more. These were done with a risset glissandi.
It would be great if moving forward, the files had more unique names.
The csound version has one giant sample at the beginning of the file
(index of 1).
The magic offset number for these files seems to be 95, btw.
The resultant differences in this pair is interesting. The differences
get larger as the file goes on. I still have to multiply by about
15000 to be able to hear it.
-C
Chris Muir
cbm@well.com
http://www.xfade.com
Are you using the same k-rate for both Csound5 and csound~? Unless kr == sr, this orc will create zipper noise through the krate lfo k2. The sound quality of this noise will depend on the krate (and also the sr). It might be safer to test this orc with everything running at the audio rate. I'd also recommend using a larger table size if you are pursuing audio cleanliness.
Eric
> .orc
> instr 1
> k2 oscil 10000, 1, 1
> a1 oscil 10000+k2, 120, 1
> chano a1, 1
> out a1
> endin
>
> .sco
>
> f1 0 16384 10 1
> ; run for 30 secs
> i1 0 30
>
----------------------------------------------------
Yes, I used the same krate in both. Also, I thought 16384 was a pretty big table size. What would you suggest, instead? I would normally use a krate = srate but I didn't for this test. I can run it again.
Ok, I did the test again with am.csd.
I specified kr == sr and removed the 'options' that were originally in the .csd header.
The old files are gone and the new ones are up:
Quote: cebec wrote on Fri, 22 August 2008 20:18
----------------------------------------------------
> Yes, I used the same krate in both. Also, I thought 16384 was a pretty big table size. What would you suggest, instead? I would normally use a krate = srate but I didn't for this test. I can run it again.
----------------------------------------------------
For rendering 16 bit audio I would use 65536. You can also improve your signal/noise ratio by using oscili instead of oscil. In real life, I like some grit in my oscillators, so I'd probably use much lower values in a performance situation.
Eric
Apparently the jury's still out (pretty literally!) on the question of whether GPL forbids mixing GPL'd DLLs with a non-GPL-compatible app (or other DLL). See
As I understand it, LGPL would be fine with dynamically linking LGPL code to a proprietary app.
I don't know that Barry Vercoe (or MIT) is likely to give anyone a hard time about the csound~ object, but given James' unequivocal response to a hypothetical supercollider~ object, he may well have deliberately chosen GPL to prohibit dynamic linking to, say, Max/MSP. Sort of a shame.
Quote: cebec wrote on Fri, 22 August 2008 12:25
----------------------------------------------------
> Hi,
> I don't know if this caused the differences but I'm using Csound5 Doubles (which uses 64-bit float for internal calculations) as the API in both examples.
> Also, here is the .orc and .sco. I did not use the noscale argument with the csound~ external. I went right from the object to an sfrecord~ with no gain or other adjustments.
>
It's hard to say without knowing more about how Csound / csound~ work exactly (not my area) - However, I'd expect that given compilation from the same csound source code for the program and the object and the same options for both (eg. 64bit), any discrepancies between the two in this test either relate to the way csound~ interfaces with Max (any post-processing), or the exact nature of the recording routines in either package.
When I posted earlier I failed to recognise that 32768.0 is a power of two and hence scaling by its reciprocal will not loose precision in a floating point calculation, as the signicand won't change, only the exponent. Therefore this shouldn't be the issue here.
Regards
Alex
Quote: cebec wrote on Fri, 22 August 2008 20:25
----------------------------------------------------
> I don't know if this caused the differences but I'm using Csound5 Doubles (which uses 64-bit float for internal calculations) as the API in both examples.
----------------------------------------------------
It depends a lot what you're doing with the numbers.
32-bit fp means a 24-bit mantissa, which is nominally 144dB S/N. This tends to be beyond the range of audibility.
However, precision artifacts can (and do!) accumulate. In general, the more involved the calculations, the bigger the artifacts.
In the example .orc file, I wouldn't expect the differences between single and double precision to amount to more than the one or two LSBs of the 32-bit value (ie, the +/-0.000001 of your decimal representation). If you've got 16-bit converters, those differences won't even make it to your DACs, let alone your ears!
Have the resultant soundfiles been uploaded anyplace so that people can do audio A/Bs? In *all* the 'quality' threads, there's been a lot of subjective "sounds better/thicker/fuller/..." comments, but I've never been _entirely_ sure what people were hearing. Also, the sources for the soundfiles would be useful. It's awful easy to be comparing apples with oranges.
Quote: Peter Castine wrote on Sat, 23 August 2008 10:55
----------------------------------------------------
> Quote: cebec wrote on Fri, 22 August 2008 20:25
> ----------------------------------------------------
> > I don't know if this caused the differences but I'm using Csound5 Doubles (which uses 64-bit float for internal calculations) as the API in both examples.
> ----------------------------------------------------
>
> It depends a lot what you're doing with the numbers.
>
> 32-bit fp means a 24-bit mantissa, which is nominally 144dB S/N. This tends to be beyond the range of audibility.
>
> However, precision artifacts can (and do!) accumulate. In general, the more involved the calculations, the bigger the artifacts.
>
> In the example .orc file, I wouldn't expect the differences between single and double precision to amount to more than the one or two LSBs of the 32-bit value (ie, the +/-0.000001 of your decimal representation). If you've got 16-bit converters, those differences won't even make it to your DACs, let alone your ears!
>
> Have the resultant soundfiles been uploaded anyplace so that people can do audio A/Bs? In *all* the 'quality' threads, there's been a lot of subjective "sounds better/thicker/fuller/..." comments, but I've never been _entirely_ sure what people were hearing. Also, the sources for the soundfiles would be useful. It's awful easy to be comparing apples with oranges.
----------------------------------------------------
Yes, these are the resultant sound files. I'm using 24-bit DACs. The purpose of this test was to determine if there are any audible or absolute differences between the output of an embedded language external and it's unembedded counterpart. I'll upload the test files later.
http://share.ovi.com/channel/cebec.csoundmax
you can already use OSC for that. Much easier...
P
On 21 Aug 2008, at 19:21, raja wrote:
>
> still, I would love it if, like the mxj object and the js object,
> someone came up with an sc object that allowed you to program
> supercollider within max(instantiating the object would
> automatically cause the localhost and internalhost servers to show
> up with full functionality, etc.).
>
> just a little pipe dream of mine, though, i guess...
Hi Kasp,
From my experience, sound "quality" of VSTis remains the same in MSP as
if they were used as standalone. This is not the case when compared to
different DAWs. For example, FL Studio has the worst sounding summing
mixer on earth, while people are still fighting to know if Logic, PT or
Nuendo sounds better than each other. A VSTi in MSP will always sounds
better than in FL Studio. In the same matter, a lot of people say Reason
rocks while a lot of other people really dislike it.
I now mostly use rtcmix~ as my main sound generator in MSP because it
*really* sounds amazing compared to MSP generated sound. It means two
things : sound "quality" is (seems to be to me) independant from the MSP
host, and it'll take a lot of hard work to generate the same sound
"quality" with MSP patching (but i'm sure it's possible, why not ? maybe
the rtcmix routines are just smarter than what i can figure to do in my
MSP patch...).
Still about rtcmix~, a simple rtcmix noise is a wet dream while compared
to a vanilla noise~ in MSP. Just try the NOISE.sco example and you'll
see what i mean. Add a few rtcmix reverb code, some rtcmix spat and
you're the king of the world.
A little something about reaktor : someone said reaktor ensembles may
have filters and saturation that make them sound better and it should be
right. But even if i just build a simple single sine wave in reaktor
without any other fancy stuff, it'll still sound "huger" than a cycle~
in MSP. It may mean that reaktor generators are antialiased or
something, maybe duplicated and phased, or even slightly detuned, like
it is in a Nord Lead (12 x oscillators for one "generator") or what you
can do with a Virus to fatten the sound using voices in unisson mode.
f.e
f.e chanfrault | aka | personal computer music
>>>>>>> http://www.personal-computer-music.com
>>>>>>> | film soundtracks, sound art, music |
Quote: f.e wrote on Thu, 28 August 2008 04:06
----------------------------------------------------
>
> I now mostly use rtcmix~ as my main sound generator in MSP because it
> *really* sounds amazing compared to MSP generated sound. It means two
> things : sound "quality" is (seems to be to me) independant from the MSP
> host, and it'll take a lot of hard work to generate the same sound
> "quality" with MSP patching (but i'm sure it's possible, why not ? maybe
> the rtcmix routines are just smarter than what i can figure to do in my
> MSP patch...).
>
> Still about rtcmix~, a simple rtcmix noise is a wet dream while compared
> to a vanilla noise~ in MSP. Just try the NOISE.sco example and you'll
> see what i mean. Add a few rtcmix reverb code, some rtcmix spat and
> you're the king of the world.
>
----------------------------------------------------
Would you mind patching this as an example and posting it? Also, it seems rtcmix~ will not work with Max 5...
Quote: cebec wrote on Thu, 28 August 2008 13:33
----------------------------------------------------
> Would you mind patching this as an example and posting it? Also, it seems rtcmix~ will not work with Max 5...
----------------------------------------------------
4.6.3 is still available.
Quote: kjg wrote on Thu, 28 August 2008 06:02
----------------------------------------------------
> Quote: cebec wrote on Thu, 28 August 2008 13:33
> ----------------------------------------------------
> > Would you mind patching this as an example and posting it? Also, it seems rtcmix~ will not work with Max 5...
> ----------------------------------------------------
>
> 4.6.3 is still available.
>
----------------------------------------------------
Yes, and I have it on both of my music computers. I just prefer to work in Max 5 these days. Still, I want to hear the difference between rtcmix~ noise and Max noise~.
different noise algorithms will sound different anyway.
even if they are all white.
So what is the verdict (I know this wasn't the initial question but
still good to know). Are csound or SC3 superior to msp in terms of
sound quality, or is what I hear (and feel from my own experience)
based on psychological mumbo jumbo? Is there an objective test to
prove this? Furthermore, what is the reason if this is the case??
I think these need to be answered before going into the difference
between csound~ and CSound standalone.
Best
P
On 28 Aug 2008, at 13:08, matt wrote:
>
> Quote: kjg wrote on Thu, 28 August 2008 06:02
> ----------------------------------------------------
>> Quote: cebec wrote on Thu, 28 August 2008 13:33
>> ----------------------------------------------------
>>> Would you mind patching this as an example and posting it? Also,
>>> it seems rtcmix~ will not work with Max 5...
>> ----------------------------------------------------
>>
>> 4.6.3 is still available.
>>
> ----------------------------------------------------
>
> Yes, and I have it on both of my music computers. I just prefer to
> work in Max 5 these days. Still, I want to hear the difference
> between rtcmix~ noise and Max noise~.
> --
> http://cebecvssimulacreant.blogspot.com/
> http://www.virb.com/cebec
Quote: peimankhosravi@gmail.com wrote on Thu, 28 August 2008 08:11
----------------------------------------------------
> So what is the verdict (I know this wasn't the initial question but
> still good to know). Are csound or SC3 superior to msp in terms of
> sound quality, or is what I hear (and feel from my own experience)
> based on psychological mumbo jumbo? Is there an objective test to
> prove this? Furthermore, what is the reason if this is the case??
>
> I think these need to be answered before going into the difference
> between csound~ and CSound standalone.
>
> Best
> P
>
> On 28 Aug 2008, at 13:08, matt wrote:
>
Well, I don't know if we're ever going to settle that question. I would say 'follow, but don't necessarily trust, your ears'.
However, the original point of this thread, I think, was to determine if there were any differences in the output of an embedded language and the language on its own.
Quote: cebec wrote on Thu, 28 August 2008 16:15
> However, the original point of this thread, I think, was to determine if there were any differences in the output of an embedded language and the language on its own.
----------------------------------------------------
Exactly, that was what Kasper started the thread for. I think we can conclude that difference between native and embedded are negligible. (and insignificant, too! :P)
I don't think you can conclude anything on which languages sounds better generally (only for specific applications), since you use different apps/languages in different ways and for different purposes, and they use different DSP algorithms. Of course they'll sound different as a result. An analog SSL E won't sound like a digital Neve Capricorn. But both are great tools, and have their uses.
What is the best way to get from A to B? A car or a motorbike? It depends, doesn't it?
regards,
kjg
Quote: kjg wrote on Thu, 28 August 2008 15:33
----------------------------------------------------
> different noise algorithms will sound different anyway.
> even if they are all white.
----------------------------------------------------
There's 'white' and then there's white.
FWIW: Supercollider and lp.shhh~ (Litter Power) use the same core algorithm for generating noise, the Tausworthe 88 algorithm.
DDZ wrote to the list, a very long time ago, that Max/MSP used the RNG algorithm from Numerical Recipes. This is a simple 32-bit Linear Congruence algorithm (with problematic parameters). I don't know if this has changed for Max 5.
I recently look at Csound to see that the default RNG used for its noise is a 16-bit (!) Linear Congruence RNG (it has an audible cycle every 0.74" at 44kHz). Csound has an alternate noise algorithm that is 31-bit Park-Miller RNG. It's slower and, worse, also has problematic parameters.
BTW, you can emulate the last three noise algorithms with lp.lll~.
Yes I understand your points. But there are some basic DSP processes
that one expects any language to be capable of achieving, and I'm
sure you would agree that the resulting sound quality is crucial. So
do you need to use an external and/or make your own oscillator or
filer in msp to get a sound quality equal to a supercollider ugen or
csound opcode? Someone also mentioned earlier that fft processes
sound nowhere as good in msp as they do in csound. I have
experimented with msp fft stuff and have concluded that the native
fft sound quality is just not good enough in msp to be usable for me.
I am sure there are ways to smooth the result but I am afraid I don't
know the math and I don't believe it should be necessary with a
higher level language. I am not saying that maxmsp is not capable, I
use it of course but mainly for the control capabilities of max and
the large array of externals available rather than msp's native
objects. Personal taste and aesthetics apart, surely there is a more
or less objective level of sound quality? I'm not even thinking about
compositional processes but basic DSP at which msp should ideally
excel, the question is does it?
Best
Peiman
On 28 Aug 2008, at 16:27, Klaas-Jan Govaart wrote:
>
> Quote: cebec wrote on Thu, 28 August 2008 16:15
>> However, the original point of this thread, I think, was to
>> determine if there were any differences in the output of an
>> embedded language and the language on its own.
> ----------------------------------------------------
>
> Exactly, that was what Kasper started the thread for. I think we
> can conclude that difference between native and embedded are
> negligible. (and insignificant, too! :P)
>
> I don't think you can conclude anything on which languages sounds
> better generally (only for specific applications), since you use
> different apps/languages in different ways and for different
> purposes, and they use different DSP algorithms. Of course they'll
> sound different as a result. An analog SSL E won't sound like a
> digital Neve Capricorn. But both are great tools, and have their uses.
>
> What is the best way to get from A to B? A car or a motorbike? It
> depends, doesn't it?
>
> regards,
> kjg
>
>
>
>
On Aug 28, 2008, at 7:33 AM, matt wrote:
> it seems rtcmix~ will not work with Max 5...
Just an update -- both rtcmix~ and chuck~ will work in max 5, but you
can't open and edit the scripting buffers directly on the object.
You can load/save the buffers to/from disk, and patches will save
buffers with the imbedded scripts properly. But I'll need to see the
new SDK before I can fix that problem. This is true, however, only
for OSX. I think the windows rtcmix~ is totally broken under max 5
right now; again SDK is needed.
There is a minor problem running these with OSX 10.5.x, but I believe
I found the bug today (one of my students was nice enough to let me
hack around on his 10.5.4 machine for an hour this afternoon). I
need to do a little more testing/debugging, but that will probably
have to wait until I (finally!) move from 10.4-land to Leopardville
on my own machine. Maybe in the next week -- kind of dumb to do it
right when the term starts, but what the heck.
maxlispj seems to run fine with everything so far, yay. One more
thing -- Anthony Palumbo sent me some sample code that may allow me
to get chuck~ running for windows soon. Thanks Anthony!
Thanks for the update, Brad! Yes, I was testing rtcmix~ on my Windows XP machine and it's definitely 'broken'. Great news about chuck~ making it to Windows, too. I do most of my work in Leopard but I use Windows often enough for this to be an exciting prospect.
earlier Peter Castine wrote:
> DDZ wrote to the list, a very long time ago, that Max/MSP used the RNG algorithm from Numerical Recipes. This is a simple 32-bit Linear Congruence algorithm (with problematic parameters). I don't know if this has changed for Max 5.
I don't know about this either, but at least the Max 5 noise~ object 'randomly' or at least differently seeds itself for multiple instances, so you can have more than one white noise source with different values - this wasn't the cae in Max 4.6, which makes it a whole lot more useful.
Earlier Peiman khosravi wrote:
>Someone also mentioned earlier that fft processes
> sound nowhere as good in msp as they do in csound. I have
> experimented with msp fft stuff and have concluded that the native
> fft sound quality is just not good enough in msp to be usable for me.
I work extensively with fft processing both in max natively and using custom written externals (which in some cases use other fft libraries and are essentially using max/msp simply for file playback/gui/hosting). I don't know csound, but unless it does a 64bit fft (possible) I don't believe the fft accuracy should be immediately noticeably different. It is certainly possible to code high quality fft processing in max/msp even if it is not easy....
There are other difficulties resulting from the problems of doing fft processing in max/msp due to the signal model (which doesn't work well for frame based representations). If you wanted to post
sound and code comparing the same processing in max / csound I would however be interested in the results and the reasons for any differences in quality.
> I am sure there are ways to smooth the result but I am afraid I don't
> know the math and I don't believe it should be necessary with a
> higher level language.
Max/msp is a higher level language than C or java perhaps, but I believe it is a common misconception that it is a higher level language than other audio text-based programming languages. I would argue that despite its easy to grasp graphical interface, it is actually a lower level language than supercollider (for instance) in which individual ugens tend to provide higher level functionality (some examples - built in granular synthesis ugens - rather than hand rolled poly~ solutions - a rich set of filters with internal coefficient calculations, rather than a smaller set in max, leaving everything else to the user with a biquad - the need in max/msp to drive play~ with a line object, rather than having this functionality grouped into one). The difficulty of implementing some types of processing in max/msp is one of the reasons I believe that myths of differences in sound quality exist...
Regards,
Alex
Hi Alex,
Csound can do 64bit processing with a double build (which is what I'm
using at the moment). However, even with the 32bit version fft
processing sounds way better in csound. You get more fft artefacts in
max when using the fft objects than in csound and the accuracy is
very noticable when it comes to more complex processes (e.g.
filtering, masking, cross synthesis). I will be more than happy to
post some examples. Perhaps we can do a little comparison here on the
list (I would love to know this for sure). Choose a sample from the
max examples folder and do some simple fft processing on it like bin
shifting and scaling. Then upload the results. I'll happily do the
csound example but someone who knows more about fft in max should
make the max examples (with patches using native objects only).
I agree that max is certainly lower level than csound, but that's not
to say that you can't make things from scratch in csound if you want
to go that way. For sure fft instruments are way way easier to
implement in supercollider and csound due to the use of signal model
in max that you mentioned. The problem is that the graphic interface
gets on the way of designing complex DSP in max, so if I wanted to
code a filter from scratch (if I knew the math in the first place)
then I would much rather do it in C or C++ and perhaps use some third
party DSP libraries. The same goes for fft, which in maxmsp is more
hassle than it's worth it, considering that the resulting quality is
not superior...
Best
Peiman
On 29 Aug 2008, at 12:02, Alex Harker wrote:
>
> earlier Peter Castine wrote:
>
>> DDZ wrote to the list, a very long time ago, that Max/MSP used the
>> RNG algorithm from Numerical Recipes. This is a simple 32-bit
>> Linear Congruence algorithm (with problematic parameters). I don't
>> know if this has changed for Max 5.
>
> I don't know about this either, but at least the Max 5 noise~
> object 'randomly' or at least differently seeds itself for multiple
> instances, so you can have more than one white noise source with
> different values - this wasn't the cae in Max 4.6, which makes it a
> whole lot more useful.
>
> Earlier Peiman khosravi wrote:
>
>> Someone also mentioned earlier that fft processes
>> sound nowhere as good in msp as they do in csound. I have
>> experimented with msp fft stuff and have concluded that the native
>> fft sound quality is just not good enough in msp to be usable for me.
>
> I work extensively with fft processing both in max natively and
> using custom written externals (which in some cases use other fft
> libraries and are essentially using max/msp simply for file
> playback/gui/hosting). I don't know csound, but unless it does a
> 64bit fft (possible) I don't believe the fft accuracy should be
> immediately noticeably different. It is certainly possible to code
> high quality fft processing in max/msp even if it is not easy....
>
> There are other difficulties resulting from the problems of doing
> fft processing in max/msp due to the signal model (which doesn't
> work well for frame based representations). If you wanted to post
> sound and code comparing the same processing in max / csound I
> would however be interested in the results and the reasons for any
> differences in quality.
>
>> I am sure there are ways to smooth the result but I am afraid I don't
>> know the math and I don't believe it should be necessary with a
>> higher level language.
>
> Max/msp is a higher level language than C or java perhaps, but I
> believe it is a common misconception that it is a higher level
> language than other audio text-based programming languages. I would
> argue that despite its easy to grasp graphical interface, it is
> actually a lower level language than supercollider (for instance)
> in which individual ugens tend to provide higher level
> functionality (some examples - built in granular synthesis ugens -
> rather than hand rolled poly~ solutions - a rich set of filters
> with internal coefficient calculations, rather than a smaller set
> in max, leaving everything else to the user with a biquad - the
> need in max/msp to drive play~ with a line object, rather than
> having this functionality grouped into one). The difficulty of
> implementing some types of processing in max/msp is one of the
> reasons I believe that myths of differences in sound quality exist...
>
> Regards,
>
> Alex
Quote: peimankhosravi@gmail.com wrote on Fri, 29 August 2008 05:42
----------------------------------------------------
> Choose a sample from the
> max examples folder and do some simple fft processing on it like bin
> shifting and scaling.
OK. Well if you tell me exactly what kind of process you want to do I'll do it. Bin-shifting I hardly ever do, because it sounds pretty bad to me normally, but I'll be happy to code it.
Can I assume you want a simple bin shift (all bins by the same amount - integer bin numbers only or fractional too?) plus a simple FFT EQ (fixed or moving?).
Let me know and I'll get on it - might not be till sunday/monday though as I have limited time/email access till then....
Regards,
Alex
cool, I think maybe starting from simple non time varying is a good
idea. And maybe also integer bin shifting with a common amount for
all bins. Mine you the csound bin shifting opcode does fractional
shifting... I'll make the csound code ready and post it with the
examples. I'll also try the same code with csound~ to go back to the
original post.
I'll post examples of these csound instruments:
straight analysis/re-synthesis
time stretching
frequency scaling: http://www.csounds.com/manual/html/
pvscale.html
frequency shifting: http://www.csounds.com/manual/html/
pvshift.html
multiplying two signals' magnitudes: http://www.csounds.com/
manual/html/pvsfilter.html
EQ: http://www.csounds.com/manual/html/pvsmaska.html
freezing: http://www.csounds.com/manual/html/pvsfreeze.html
smoothing: http://www.csounds.com/manual/html/pvsmooth.html
blurring: http://www.csounds.com/manual/html/pvsblur.html
Also we should probably use two samples, one percussive and another
more sustained. Is anyone experienced with supercollider willing to
do the same there? It would be an interesting comparison ;-)
Best
Peiman
On 29 Aug 2008, at 15:31, Alex Harker wrote:
>
> Quote: peimankhosravi@gmail.com wrote on Fri, 29 August 2008 05:42
> ----------------------------------------------------
>> Choose a sample from the
>> max examples folder and do some simple fft processing on it like bin
>> shifting and scaling.
>
> OK. Well if you tell me exactly what kind of process you want to do
> I'll do it. Bin-shifting I hardly ever do, because it sounds pretty
> bad to me normally, but I'll be happy to code it.
>
> Can I assume you want a simple bin shift (all bins by the same
> amount - integer bin numbers only or fractional too?) plus a simple
> FFT EQ (fixed or moving?).
>
> Let me know and I'll get on it - might not be till sunday/monday
> though as I have limited time/email access till then....
>
> Regards,
>
> Alex
f.e schrieb:
> But even if i just build a simple single sine wave in reaktor without
> any other fancy stuff, it'll still sound "huger" than a cycle~ in
> MSP. It may mean that reaktor generators are antialiased or
> something, maybe duplicated and phased, or even slightly detuned,
> like it is in a Nord Lead (12 x oscillators for one "generator") or
> what you can do with a Virus to fatten the sound using voices in
> unisson mode.
If that is the case, the only way to fatten a sine is to distort it. Not
necessarily a quality feature, especially if you didn't ask for it...
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
peiman khosravi schrieb:
> The same goes for fft, which in maxmsp is more hassle than it's worth
> it, considering that the resulting quality is not superior...
Are you talking about fft~ or pfft~??? If there is a difference, there
should be a reason. If compared the two results, listening to the
difference signal should reveal some insight...
I wouldn't expect fft~ to be exact with scheduler triggered windowing,
but pfft~ should be fine. In the end it should be the same math behind it...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
I'm referring to pfft~.
Best
Peiman
On 29 Aug 2008, at 23:49, Stefan Tiedje wrote:
> peiman khosravi schrieb:
>> The same goes for fft, which in maxmsp is more hassle than it's worth
>> it, considering that the resulting quality is not superior...
>
> Are you talking about fft~ or pfft~??? If there is a difference,
> there should be a reason. If compared the two results, listening to
> the difference signal should reveal some insight...
> I wouldn't expect fft~ to be exact with scheduler triggered
> windowing, but pfft~ should be fine. In the end it should be the
> same math behind it...
>
> Stefan
>
> --
> Stefan Tiedje------------x-------
> --_____-----------|--------------
> --(_|_ ----|-----|-----()-------
> -- _|_)----|-----()--------------
> ----------()--------www.ccmix.com
>
Quote: Peter Castine wrote on Fri, 22 August 2008 14:53
----------------------------------------------------
> I don't know that Barry Vercoe (or MIT) is likely to give anyone a hard time about the csound~ object, but given James' unequivocal response to a hypothetical supercollider~ object, he may well have deliberately chosen GPL to prohibit dynamic linking to, say, Max/MSP. Sort of a shame.
----------------------------------------------------
Quote: Chris Muir wrote on Fri, 22 August 2008 11:19
----------------------------------------------------
>
> On Aug 22, 2008, at 4:28 AM, Timothy Place wrote:
> > This is why it is not:
> > http://electrotap.net/blog/show/192
>
>
> Frackin' religious zealots.
>
> -C
>
> Chris Muir
> cbm@well.com
> http://www.xfade.com
----------------------------------------------------
Alex and Eric were kind enough to draw my attention to this debate while chatting at ICMC the other day.
Firstly, I think this is a fascinating discussion. I think James McCartney's observation about SC lending itself to certain ways of working is perhaps the most likely candidate for explaining this impression overall, and as someone who has used both Max and SC I'd just add that I think that it's very interesting to consider the ways in which a particular environment can structure the way you work, or encourage different approaches to music making. This is especially true given that it seems likely that we're unaware of this happening much of the time.
Regarding this GPL business: James has taken some flack over this in the past, in this forum and elsewhere. Although his response that Tim quotes on the Electrotap blog is typically brief, I know James to be a very good natured and generous person. I would thus be very surprised if he chose to release SC 3 under the GPL in order to 'prevent' using it with Max (you have the OSC route to do this anyway, which I know Eric sometimes uses), or for reasons of software freedom 'zealotry'.
For many years SC was a proprietary closed source product, just like Max, and was the primary source of James' livelihood. He certainly didn't have any 'religious' issues with that at the time. When he went to work for Apple, he chose to make it free and open source. He was in no way obligated to do this of course, and could probably have sold it to someone else had he wanted to. Given that he was giving the community his livelihood, I think it was not unreasonable of him to place some conditions on how it would be used (as often happens with acts of charity).
That I think is what the GPL does in this case. It allows other people to use his work and distribute their additions to it (and even to profit from them) providing they are willing to be equally generous and allow others to benefit from their work as they have from his. I don't think that's unfair.
If SC was still closed source no one would expect James to allow a Max external.
Similarly, if I were to demand that Cycling give me the code to all the MSP objects so that I could port them to SC, people would think I was nuts.
I don't see how encouraging a process of generosity and sharing (as was his right to do) between those who benefit from his work is zealous, or unreasonable, or even a shame, and frankly I think suggesting otherwise is a little ungracious.
With respect,
Scott
On Aug 30, 2008, at 6:34 AM, Scott Wilson wrote:
> That I think is what the GPL does in this case. It allows other
> people to use his work and distribute their additions to it (and
> even to profit from them) providing they are willing to be equally
> generous and allow others to benefit from their work as they have
> from his. I don't think that's unfair.
Right, but that's not all the GPL says. There are other licenses that
would allow for any kind of code to be built, but that would also
require the code to be open. If SC was licensed under a license that
allowed plug-ins, but still required people to share source to those
plug-ins, wouldn't that be better? Why choose a license that precludes
some implementations?
If an open-source version of a SC external for Max were allowed under
the SC license, how would that be a bad thing? In the eyes of the FSF/
GPL, it would be bad because it aids and abets a piece of closed
software. It's not enough for the GPL to ensure that a chunk of code
stays open, they also have to try to impede closed software in the
process.
> If SC was still closed source no one would expect James to allow a
> Max external.
Of course, but it isn't closed source any more. It is "free software",
at least as long as you don't try to use it dynamically linked with
commercial software, or even software created with a more permissive
open source license.
> Similarly, if I were to demand that Cycling give me the code to all
> the MSP objects so that I could port them to SC, people would think
> I was nuts.
Right, but MSP is a commercial venture, and is not open source.
> I don't see how encouraging a process of generosity and sharing (as
> was his right to do) between those who benefit from his work is
> zealous, or unreasonable, or even a shame, and frankly I think
> suggesting otherwise is a little ungracious.
All the benefits you list would also be true if the code was licensed
under a more permissive open source license, but with the benefit of
enabling more people to share, because more types of implementations
could be created. It is not enough for the FSF to have a "free
software" code tree, they have to try to enforce a "free software"
orchard ecosystem.
I don't have an issue with the sharing/open source, just with the
restrictions that the GPL puts on what kind of programs can be built.
There are myriad open source licenses. The GPL seems to be the most
restrictive, and the one with the largest degree of religious fervor,
hence my use of the word zealot.
Reading this page on the GNU site, may give you an idea of why I think
the word zealot is appropriate:
http://www.gnu.org/licenses/why-not-lgpl.html
-C
Chris Muir
cbm@well.com
http://www.xfade.com
Quote: Chris Muir wrote on Sat, 30 August 2008 11:11
----------------------------------------------------
>
> On Aug 30, 2008, at 6:34 AM, Scott Wilson wrote:
>
> > That I think is what the GPL does in this case. It allows other
> > people to use his work and distribute their additions to it (and
> > even to profit from them) providing they are willing to be equally
> > generous and allow others to benefit from their work as they have
> > from his. I don't think that's unfair.
>
> Right, but that's not all the GPL says. There are other licenses that
> would allow for any kind of code to be built, but that would also
> require the code to be open. If SC was licensed under a license that
> allowed plug-ins, but still required people to share source to those
> plug-ins, wouldn't that be better? Why choose a license that precludes
> some implementations?
>
> If an open-source version of a SC external for Max were allowed under
> the SC license, how would that be a bad thing? In the eyes of the FSF/
> GPL, it would be bad because it aids and abets a piece of closed
> software. It's not enough for the GPL to ensure that a chunk of code
> stays open, they also have to try to impede closed software in the
> process.
Well, James would have to answer why he chose the GPL rather than any alternatives, and I don't know his opinion on its finer points or any of the debates surrounding it. However I suspect the point here is not to impede closed software, and I think 'impede' is an extremely loaded choice of word on your part.
Nobody would be accusing James of 'impeding closed software' if he had not given it away, or had sold it to someone who kept it closed, so how is he impeding them now?
Is Cycling 'impeding' SC users by not giving them the MSP code?
If I refuse to share with you because you won't share with me, how am I 'impeding' you?
People have 'eyes,' not the GPL, and not every piece of software which uses it is from the FSF. Choosing the GPL does not mean you agree with everything Richard Stallman says, but even if you do, that doesn't mean closed software companies should have the right to do anything they want with your intellectual property.
>
>
> > If SC was still closed source no one would expect James to allow a
> > Max external.
>
> Of course, but it isn't closed source any more. It is "free software",
> at least as long as you don't try to use it dynamically linked with
> commercial software, or even software created with a more permissive
> open source license.
>
>
> > Similarly, if I were to demand that Cycling give me the code to all
> > the MSP objects so that I could port them to SC, people would think
> > I was nuts.
>
> Right, but MSP is a commercial venture, and is not open source.
>
And SC is GPL'd software, not BSD or LGPL or anything else. I'm not sure why you seem to think the fact that it's open source should entail that anyone should be entitled to do what they want with it without restriction. But sorry if I've misunderstood.
>
> > I don't see how encouraging a process of generosity and sharing (as
> > was his right to do) between those who benefit from his work is
> > zealous, or unreasonable, or even a shame, and frankly I think
> > suggesting otherwise is a little ungracious.
>
>
> All the benefits you list would also be true if the code was licensed
> under a more permissive open source license, but with the benefit of
> enabling more people to share, because more types of implementations
> could be created. It is not enough for the FSF to have a "free
> software" code tree, they have to try to enforce a "free software"
> orchard ecosystem.
Only with respect to their own intellectual property, and that is the crucial point that you leave out of your argument.
What is wrong with saying that you will only share your work (effectively his life's work in James' case) with people who will equally share? The LGPL would allow any software company to take his intellectual property, package it and sell it as an upgrade, without adding or sharing anything of their own. Why is it so strange or zealous to decide that's not okay in a particular case?
Certainly some software projects are fine with that, and choose the LGPL or something similar. I think that's okay, but I think it's okay to want to prevent that as well. This is about people having the freedom to decide how their stuff is used, and who can profit from it. Proprietary software companies have that right, and I don't see why making a project open should mean you should have to surrender it.
The GPL is basically about distribution in fact; another point which usually gets lost. IANAL, but as I understand it, you or any other Max user could make a supercollider~ external for your own use. You are only 'impeded' from distributing or selling it.
>
> I don't have an issue with the sharing/open source, just with the
> restrictions that the GPL puts on what kind of programs can be built.
> There are myriad open source licenses. The GPL seems to be the most
> restrictive, and the one with the largest degree of religious fervor,
> hence my use of the word zealot.
>
> Reading this page on the GNU site, may give you an idea of why I think
> the word zealot is appropriate:
> http://www.gnu.org/licenses/why-not-lgpl.html
>
Well as far as I know, James didn't write that, so I'm not really sure what your point is. He developed SC as a proprietary project for years, and now works for Apple. Not exactly a Stallman clone.
So far you've offered an ad hominem attack, and guilt by association. What you've not done (IMO at least) is explained why the kind of control over intellectual property that the GPL involves is any less reasonable than the kind Cycling or Microsoft any other proprietary software company enjoys.
S.
Exactly. One of the things that struck me about this discussion is that people are reporting subjective experiences of differences in things (such as sine waves) that really shouldn't vary between programs unless one of the programs is "doing it wrong." I'm not saying that people who are hearing these differences are mistaken, as there may very well be a difference in sound quality. But if something as definite as a sine wave sounds better in one program than another, then probably one of two things is going on:
1. One program is somehow enhancing or coloring the sine wave to make it sound more pleasant, in which case it is no longer a sine wave and we are comparing apples and oranges.
2. One program is not using correct math.
But I suspect that, as other people have mentioned, part of the issue may not be the capabilities of the program, but rather the types of things the program does easily. For example, it makes sense that the cycle~ object might not be totally ideal, as it uses a wavetable of 512 samples and interpolates between them. It would be possible to create a larger wavetable that could perhaps be more accurate, but it's much quicker to just use cycle~. Same goes for filters and fft. The thing that troubles me is why CSound would sound better than csound~. If this is true, then it would suggest that there is a limit to how accurate Max/MSP can be, no matter what the user does. And that's kind of depressing.
Stephen
Quote: Stefan Tiedje wrote on Fri, 29 August 2008 18:48
----------------------------------------------------
> If that is the case, the only way to fatten a sine is to distort it. Not
> necessarily a quality feature, especially if you didn't ask for it...
>
> --
> Stefan Tiedje------------x-------
> --_____-----------|--------------
> --(_|_ ----|-----|-----()-------
> -- _|_)----|-----()--------------
> ----------()--------www.ccmix.com
>
>
----------------------------------------------------
Quote: Stephen Lee wrote on Sat, 30 August 2008 14:01
----------------------------------------------------
The thing that troubles me is why CSound would sound better than csound~. If this is true, then it would suggest that there is a limit to how accurate Max/MSP can be, no matter what the user does. And that's kind of depressing.
>
Well, I don't think anyone's said that, yet. And the tests show that any differences must be gain multiplied over 1500 times in order to be audible.
On Aug 30, 2008, at 12:50 PM, Scott Wilson wrote:
> However I suspect the point here is not to impede closed software,
> and I think 'impede' is an extremely loaded choice of word on your
> part.
I don't think so, I think that impede is a pretty good word choice,
actually. That may not have been James' intent, but it is certainly a
result of his choice of the GPL. One of the main differences between
the GPL and the LGPL is just this sort of impediment. The GPL is
trying to create a whole idealistic software ecosystem, where
everything must be distributed in a FSF-scantioned "free" manner.
The LGPL allows for a richer ecosystem, where within still fairly
strict rules, "free" and non-"free" software can be mixed in a given
environment. csound is licensed under the LGPL, and has very wide
deployment. It has all the same benefits and requirements of
bidirectional source sharing that the GPL has, just with a couple
fewer restrictions that allow for building a plug-in for some
commercial piece of software.
> Nobody would be accusing James of 'impeding closed software' if he
> had not given it away, or had sold it to someone who kept it closed,
> so how is he impeding them now?
He is impeding them now, by his choice of GPL, the most restrictive
"free software" license I know of. Certainly people are free to do
some stuff with SC as allowed by the GPL, but are not free to do other
stuff. That impedes people who want to do things with SC that the GPL
does not allow that would be allowed under the LGPL.
> Is Cycling 'impeding' SC users by not giving them the MSP code?
A straw man argument, but... certainly they are if a SC user wanted to
use some MSP code inside of SC. But it was always so with commercial
software.
> If I refuse to share with you because you won't share with me, how
> am I 'impeding' you?
There's sharing and there's sharing. The GPL says that all things that
the GPL is linked with, even in the case of dynamic linking such as a
plug-in or DLL must be "free," not just the specific code involved.
I share a fair amount of stuff, but I would never use the GPL, because
of it's "viral nature."
I fully support the goal of having thing that are done with the SC
code passed back to the SC community, which the LGPL accomplishes
every bit as well as the GPL. I don't support the goal of having
everything that uses that source be required to be GPL as well.
> People have 'eyes,' not the GPL, and not every piece of software
> which uses it is from the FSF. Choosing the GPL does not mean you
> agree with everything Richard Stallman says, but even if you do,
> that doesn't mean closed software companies should have the right to
> do anything they want with your intellectual property.
What you say here is correct, but no one is arguing that.
What I am saying is that it's unfortunate that by the choice of the
GPL, as an independent developer, I am not free to make a
SuperCollider plugin for Max for distribution on my web site, if I
wanted to. Even though I would fully intended to freely share the
derived source as well as a binary for this plugin, the GPL would not
allow me to do this (although the LGPL would). I find it ridiculous
that I would somehow have to magically cause the source of Max to be
released under the GPL to allow me to make a SC plug-in for Max.
-C
For me the issue gets a little muddled technically. I know the
license is clear about restrictions on 'plugins' into commercial
software (which I guess gets around the fact that non-linux users are
essentially 'plugging in' the code), but imagine this scenario:
1. I set up max/msp to communicate with SC via OSC, and I also use
soundflower or jack to route the audio to/from max/msp
2. I get tired of typing in all the objects to do this, so I create
an abstraction -- call it "sc3~" for fun -- with control and audio
connections as inlets and outlets. I still have to set up soundlower/
jack separately and I have to start SC to do this.
3. I get tired of having to set up soundflower/jack and start SC, so
with a little scripting I include it in my "sc3~" abstraction; it
works automagically.
4. I get annoyed at OSC and soundflower/jack, so I write my own
little sockety-thing ugens in SC and objects in max/msp to do the
work in place of these. The connection now happens even more
automagically. I get really fancy and the max/msp ugen starts up
scserver and sclang or whatever for me from inside the object. Yikes!
5. I think "what the heck, why do the socket when with a little less
coding(!) I can write to/from the two environments directly." So I
write the appropriate SC ugens and modify my max/msp "sc3~" object to
do this. SC is started via a dynamically-loaded library.
At what point have I crossed the line? Probably step 5, but the
progression I outlined begs the obvious question -- what's the real
difference here? And why does it make sense to put in place a
prohibition at any step above, when essentially the same operations
(control and audio to/from the two environments) take place at every
stage?
Quote: Chris Muir wrote on Sat, 30 August 2008 15:01
----------------------------------------------------
> He is impeding them now, by his choice of GPL, the most restrictive
> "free software" license I know of.
Ah, but presumably less than he was before, and less of an impediment than all commercial software, yes?
> Certainly people are free to do
> some stuff with SC as allowed by the GPL, but are not free to do other
> stuff. That impedes people who want to do things with SC that the GPL
> does not allow that would be allowed under the LGPL.
Yes, and if I want to port MSP objects to PD Cycling would similarly impede me. The difference is I wouldn't call them zealots for that. They're under no obligation to allow me to do that, just as James is under no obligation to allow these people you mention to do the things they want.
Obviously if he had released it under the LGPL that would be less restrictive. But that still doesn't explain how an act of pretty impressive generosity amounts to zealotry in your book.
>
>
> > Is Cycling 'impeding' SC users by not giving them the MSP code?
>
> A straw man argument
Yes, the result of your premises.
, but... certainly they are if a SC user wanted to
> use some MSP code inside of SC. But it was always so with commercial
> software.
Then by your definition this sort of impeding is pretty much commonplace. Does that make Cycling 74 and Apple zealots as well?
> What I am saying is that it's unfortunate that by the choice of the
> GPL, as an independent developer, I am not free to make a
> SuperCollider plugin for Max for distribution on my web site, if I
> wanted to. Even though I would fully intended to freely share the
> derived source as well as a binary for this plugin, the GPL would not
> allow me to do this (although the LGPL would). I find it ridiculous
> that I would somehow have to magically cause the source of Max to be
> released under the GPL to allow me to make a SC plug-in for Max.
Magic tricks aside, why you think you should be entitled to?
S.
Great post, Brad!
That really brought it home for me that the main reason to care about an sc3~ external is that it's a PITA to run SC3 into Max via Jack or Soundflower, and there are some potentially interesting synergies to explore between SC3 and Max that one tends not to, thanks to the PITA.
>>
And why does it make sense to put in place a
prohibition at any step above, when essentially the same operations
(control and audio to/from the two environments) take place at every
stage?
>>
I suspect that James McCartney might have an interesting answer to this question.
Eric
On Aug 30, 2008, at 2:39 PM, Brad Garton wrote:
> At what point have I crossed the line? Probably step 5, but the
> progression I outlined begs the obvious question -- what's the real
> difference here? And why does it make sense to put in place a
> prohibition at any step above, when essentially the same operations
> (control and audio to/from the two environments) take place at every
> stage?
I agree. These distinctions are all aimed at inconveniencing people
who chose to use proprietary software.
I wonder at what point the FSF might get involved if there was a
tutorial project to take the SC code and provide enough information to
allow people to easily compile their own versions of a SC Max external?
What if it went beyond instructions, and included something like sed
scripts to generate code for an external?
-C
Chris Muir
cbm@well.com
http://www.xfade.com
(I'm replying to parts of a couple of posts by Scott)
On Aug 30, 2008, Scott Wilson wrote:
> And SC is GPL'd software, not BSD or LGPL or anything else. I'm not
> sure why you seem to think the fact that it's open source should
> entail that anyone should be entitled to do what they want with it
> without restriction. But sorry if I've misunderstood.
>>
I never said that. I recognize that there is no such entitlement
granted. I also recognize that that's an unfortunate turn of events,
fairly unique to the use of the GPL.
Also, it's worth pointing out that the FSF would probably argue that
something licensed under the GPL is NOT open source.
> What is wrong with saying that you will only share your work
> (effectively his life's work in James' case) with people who will
> equally share?
I do respect the effort poured into Supercollider, and am glad he
released the source so that SC users have a path forward.
> The LGPL would allow any software company to take his intellectual
> property, package it and sell it as an upgrade, without adding or
> sharing anything of their own.
Nothing in the GPL precludes someone grabbing the source today,
packaging it, and selling it today. True, they would have to release
their own source (if any) as part of the deal, but...
> Quote: Chris Muir wrote on Sat, 30 August 2008 15:01
> ----------------------------------------------------
>
>> He is impeding them now, by his choice of GPL, the most restrictive
>> "free software" license I know of.
>
> Ah, but presumably less than he was before, and less of an
> impediment than all commercial software, yes?
For the way I like to work, it's about the same actually. I tend to
pick an environment or two and work within them. For better or worse,
Max is that environment for me, right now. I think that the fact the
SC has been able to move forward is nice from an abstract POV, but
from a practical POV, for me, it doesn't impact me much. For me, If I
have to cobble together a system with multiple programs wired together
with things like Jack and OSC it's too much work, at least for live use.
> Obviously if he had released it under the LGPL that would be less
> restrictive. But that still doesn't explain how an act of pretty
> impressive generosity amounts to zealotry in your book.
The zealotry is the Free Software Foundation's, and is only James' to
the extent that he is a booster of the GPL.
James is certainly free to choose whatever license he wants to, just
as I am free to dislike his choice and whinge about it.
>> What I am saying is that it's unfortunate that by the choice of the
>> GPL, as an independent developer, I am not free to make a
>> SuperCollider plugin for Max for distribution on my web site, if I
>> wanted to.
> Magic tricks aside, why you think you should be entitled to?
Well, it seems like a reasonable thing to be able to do with "free"
software, IMO. If you look at the FSF definition of free software http://www.gnu.org/philosophy/free-sw.html
, making a SC external for Max would qualify as reasonable uses of
freedoms 0-3, if it wasn't for the anti-commercial software clauses in
the GPL itself. This goes to the root of the difference between open
source and "free" software.
BTW, there's already an AU-wrapped version of SC, which I believe is
also probably against the rules of the GPL. Would you argue against
that, too? I'm sure people find it useful.
Perhaps we should take further discussion, if any, to email? The Max
list doesn't seem like the right place for this.
-C
Hey Brad,
Quote: Bradford Garton wrote on Sat, 30 August 2008 15:39
----------------------------------------------------
> For me the issue gets a little muddled technically. I know the
> license is clear about restrictions on 'plugins' into commercial
> software (which I guess gets around the fact that non-linux users are
> essentially 'plugging in' the code), but imagine this scenario:
...
> At what point have I crossed the line? Probably step 5, but the
> progression I outlined begs the obvious question -- what's the real
> difference here? And why does it make sense to put in place a
> prohibition at any step above, when essentially the same operations
> (control and audio to/from the two environments) take place at every
> stage?
These sort of points are well made, but I think the thing to remember is that the problem with the application of the license is a 'technical' one. The technical issues result in a situation where it's difficult to apply a few limitations to what people can do without allowing them to do some similar things. It does not follow from that that the only sensible choices are complete limitation or complete permissiveness.
S.
Quote: Chris Muir wrote on Sat, 30 August 2008 19:12
----------------------------------------------------
>
> On Aug 30, 2008, at 2:39 PM, Brad Garton wrote:
>
> > At what point have I crossed the line? Probably step 5, but the
> > progression I outlined begs the obvious question -- what's the real
> > difference here? And why does it make sense to put in place a
> > prohibition at any step above, when essentially the same operations
> > (control and audio to/from the two environments) take place at every
> > stage?
>
>
> I agree. These distinctions are all aimed at inconveniencing people
> who chose to use proprietary software.
You seem awfully sure of the motivations of a rather large number of people. An equally plausible reason to choose the GPL or the numerous similar licenses would be to make a compromise between total freedom and total limitation.
You've argued that the GPL is the 'most restrictive' of open source licenses. Whether that's true or not, I don't know, but it is worth remembering that it is nevertheless far less restrictive than the vast majority of software licenses in general.
You also called it 'viral.' A virus is something that invades your body against your will. Nobody is forcing supercollider into MSP. On the contrary, you are complaining because the license does not allow you to force it in.
>
> I wonder at what point the FSF might get involved if there was a
> tutorial project to take the SC code and provide enough information to
> allow people to easily compile their own versions of a SC Max external?
The FSF is not involved in SC at all, AFAIK, so I suspect never. It is not their intellectual property, and they are not the ones who have licensed it.
S.