Sound quality in MAX....


    Aug 20 2008 | 8:06 pm
    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

    • Aug 20 2008 | 8:15 pm
      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 >
    • Aug 20 2008 | 8:32 pm
      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 >
    • Aug 20 2008 | 8:43 pm
      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 >> > >
    • Aug 20 2008 | 8:51 pm
      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
    • Aug 20 2008 | 8:53 pm
      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
    • Aug 20 2008 | 8:59 pm
      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 >>> >> >> >
    • Aug 20 2008 | 9:00 pm
      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
    • Aug 20 2008 | 9:06 pm
      > >@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
    • Aug 20 2008 | 9:46 pm
      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 :)
    • Aug 20 2008 | 10:29 pm
      Just a word, my Csound's csd files sound better in csound than in [csound~].
    • Aug 20 2008 | 10:44 pm
      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 :)
    • Aug 20 2008 | 11:57 pm
      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....
    • Aug 21 2008 | 6:39 am
      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?
    • Aug 21 2008 | 8:06 am
      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 >
    • Aug 21 2008 | 9:42 am
      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
    • Aug 21 2008 | 11:24 am
      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
    • Aug 21 2008 | 1:54 pm
      "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. >
    • Aug 21 2008 | 2:49 pm
      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.
    • Aug 21 2008 | 3:30 pm
      >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
    • Aug 21 2008 | 3:53 pm
      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
    • Aug 21 2008 | 3:57 pm
      Sure, I can do this. What Csound .csd to use, though?
    • Aug 21 2008 | 3:57 pm
      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?
    • Aug 21 2008 | 4:26 pm
      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
    • Aug 21 2008 | 4:28 pm
      also using something like Risset's Bell instrument might be a good generator since I believe it exists in Csound, Max/MSP and Supercollider
    • Aug 21 2008 | 4:39 pm
      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:
    • Aug 21 2008 | 5:00 pm
      I compared the two using Visual Analyzer's spectrum analyzer and phase analyzer and I could not discern any differences between the two.
    • Aug 21 2008 | 5:43 pm
      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
    • Aug 21 2008 | 5:55 pm
      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.
    • Aug 21 2008 | 6:21 pm
      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...
    • Aug 21 2008 | 6:37 pm
    • Aug 21 2008 | 7:42 pm
      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
    • Aug 21 2008 | 8:33 pm
      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
    • Aug 22 2008 | 4:39 am
      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 >
    • Aug 22 2008 | 4:45 am
      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...
    • Aug 22 2008 | 5:22 am
      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
    • Aug 22 2008 | 7:41 am
      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
    • Aug 22 2008 | 7:51 am
      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
    • Aug 22 2008 | 8:00 am
      Quote: mzed wrote on Thu, 21 August 2008 13:42 ---------------------------------------------------- > > You can drive SC with OSC, if you like. Not exactly the same, but handy. > > mz > ----------------------------------------------------
      Yes, indeed, as Klipp AV (Fredrik Olafsson and Nick Collins) have proven the benefits thereof, I am truly impressed, but I really wish for some kind of hard-coded symbiosis. But you are right, this is where I plan to go... eventually.
    • Aug 22 2008 | 8:09 am
      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
    • Aug 22 2008 | 8:12 am
      Ah, I C, Jeremy, that would explain why I stick to Max alone so devotedly... well... that and the new presentation-mode-opacity-level-ass-kickin-interface-design possibilities...
    • Aug 22 2008 | 8:28 am
      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
    • Aug 22 2008 | 9:08 am
      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 > >
    • Aug 22 2008 | 9:56 am
      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
    • Aug 22 2008 | 11:07 am
      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
    • Aug 22 2008 | 11:28 am
      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.
      best, Tim
    • Aug 22 2008 | 12:16 pm
      Thanks for the clarification!
      jb
    • Aug 22 2008 | 12:20 pm
      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
    • Aug 22 2008 | 12:52 pm
      > 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
    • Aug 22 2008 | 1:18 pm
      > 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
    • Aug 22 2008 | 2:07 pm
      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...
    • Aug 22 2008 | 2:07 pm
      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.
    • Aug 22 2008 | 3:11 pm
      > 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
    • Aug 22 2008 | 3:21 pm
      > > 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
    • Aug 22 2008 | 5:19 pm
      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
    • Aug 22 2008 | 5:32 pm
      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
    • Aug 22 2008 | 6:09 pm
      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
    • Aug 22 2008 | 6:12 pm
      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....
    • Aug 22 2008 | 6:25 pm
      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
    • Aug 22 2008 | 7:00 pm
      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
    • Aug 22 2008 | 7:15 pm
      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 > ----------------------------------------------------
    • Aug 22 2008 | 7:18 pm
      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.
    • Aug 22 2008 | 7:30 pm
      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:
    • Aug 22 2008 | 7:36 pm
      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
    • Aug 22 2008 | 8:53 pm
      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.
    • Aug 23 2008 | 2:04 am
      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
    • Aug 23 2008 | 4:55 pm
      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.
    • Aug 23 2008 | 5:30 pm
      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
    • Aug 28 2008 | 8:29 am
      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...
    • Aug 28 2008 | 10:06 am
      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 |
    • Aug 28 2008 | 11:33 am
      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...
    • Aug 28 2008 | 12:02 pm
      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.
    • Aug 28 2008 | 12:05 pm
      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~.
    • Aug 28 2008 | 1:33 pm
      different noise algorithms will sound different anyway. even if they are all white.
    • Aug 28 2008 | 2:11 pm
      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
    • Aug 28 2008 | 2:15 pm
      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.
    • Aug 28 2008 | 3:26 pm
      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
    • Aug 28 2008 | 9:45 pm
      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~.
    • Aug 28 2008 | 10:11 pm
      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 > > > >
    • Aug 28 2008 | 10:27 pm
      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!
    • Aug 28 2008 | 10:54 pm
      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.
    • Aug 29 2008 | 11:02 am
      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
    • Aug 29 2008 | 11:42 am
      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
    • Aug 29 2008 | 2:31 pm
      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
    • Aug 29 2008 | 8:11 pm
      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
      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
    • Aug 29 2008 | 10:48 pm
      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
    • Aug 29 2008 | 10:49 pm
      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
    • Aug 30 2008 | 10:05 am
      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 >
    • Aug 30 2008 | 1:34 pm
      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
    • Aug 30 2008 | 5:11 pm
      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
    • Aug 30 2008 | 7:50 pm
      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.
    • Aug 30 2008 | 8:01 pm
      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 > > ----------------------------------------------------
    • Aug 30 2008 | 8:04 pm
      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.
    • Aug 30 2008 | 9:01 pm
      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
    • Aug 30 2008 | 9:39 pm
      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?
    • Aug 30 2008 | 10:00 pm
      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.
    • Aug 30 2008 | 10:06 pm
      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
    • Aug 31 2008 | 1:12 am
      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
    • Aug 31 2008 | 7:15 am
      (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
    • Aug 31 2008 | 7:40 am
      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.
    • Aug 31 2008 | 8:01 am
      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.