From: owner-sc-users-digest@lists.io.com (sc-users-digest) To: sc-users-digest@lists.io.com Subject: sc-users-digest V1 #16 Reply-To: sc-users Sender: owner-sc-users-digest@lists.io.com Errors-To: owner-sc-users-digest@lists.io.com Precedence: bulk sc-users-digest Wednesday, November 25 1998 Volume 01 : Number 016 ---------------------------------------------------------------------- Date: Wed, 25 Nov 1998 13:19:33 +0100 From: "Iannis Zannos" <---@---.---> Subject: Re: [fwd] DIVE into mpeg4 Dear Eric, thanks for the extensive response. It really made me understand your motivation the current directions and the point about interoperability and standards better - but I will not go into details. Just one point: >I don't think SAOL competes with any particular >tool, but in the long run it may help to improve the >space of all tools for audio. >that shouldn't be discounted easily. Part of my goal in >working on synthesis within MPEG was to make flexible >software synthesis into an *industry* rather than a hobby. >If this can be accomplished, the profile of all such tools >will be raised ("a rising tide lifts all boats") and there >will be more attention to be committed to the true advances >in language design such as those represented by SC. These are commendable goals and I believe they are duly appreciated. At a practical level, most of us in this list are dependent on the industry and/or advanced developers like James for the applications. The preference is to connect existing applications by linking existing code, configuring, providing the small missing parts etc. while leaving the development of the applications to institutions with more muscle. Thus I think if musical people such as in this list are to be involved in MPEG4 at all, this can only happen either after such applications are available, or better, in cooperation with industrial partners that provide the technological muscle needed. So far I have found it difficult to raise the interest of suitable parties in such a cooperation, although I think that such cooperatios are required to "raise the tide" as you are describing. Yet thanks for pointing again in this direction, persistence is necessary. Best regards, Iannis Zannos SIM Tiergartenstr. 1, D-10785 Berlin, Germany Fax: +49 30 25481172 - ---------- >From: Eric Scheirer <---@---.---> >To: sc-users@lists.io.com >Subject: Re: [fwd] DIVE into mpeg4 >Date: Tue, 24 Nov 1998 8:08 PM > >Dear Iannos, > >Your comments are very well articulated and open many >fascinating avenues for discussion. I take your belief >that this topic is not off-topic for the SC as an invitation >to continue. :) Others please complain if this is considered >clutter. > >> In the above sense, I would like to respond briefly to your >> prompt here. I admit in advance that my knowledge of MPEG4 is >> not so deep and complete - so please excuse any misconceptions. >> If the issues raised below have already been considered and >> resolved, I would welcome any pointers or clarifications. > >Yes, of course. MPEG-4 is very difficult to approach for the >first time, and part of the responsibility of the developers is >to engage in outreach to help the broad multimedia community >really understand what is being standardized. > >> We thought that SAOL was too encumbered by its lineage (CSound, >> orchestra-score model), > >Yes, I agree that in many senses SAOL is an "old" language. >I have never claimed any differently, and in fact, I think >there is a place in music-language research for both robust >old languages and flexible, advanced, new languages. This >is the case in general-purpose programming languages: on >one side are C, C++, Fortran, Lisp, etc, that are standards- >based and whose properties are well-understand and there are >many powerful systems for developing with them and using them. >On the other side are Python, ML, Oberon, Eiffel, etc, which >have much more powerful capabilities but a narrower distribution. > >I see the SAOL-SC comparison as somewhat similar. This is not >to say that things stay the same forever; there is a general >progression from languages on the "advanced" side to become >standardized and broadly applicable (C++ is probably the most >recent to make this transition). > >> On the other hand, "the Industry" is >> looking for standardized technologies that offer high >> resolution, meet the requirements raised by the evolving needs >> of the consumer at a "least common denominator" level(!), while >> being cheap both in data and in technology (may be likened to >> "quantity"). > >I think you underestimate the importance of interoperability >here. It is a real, practical problem when systems evolve >in an out-of-control fashion (I'm thinking of Csound here) >or in multiple different directions at the same time. MPEG, >as a body, is less responsive to "lowest common denominator" >issues (that would be the MIDI folks :-) than it is to >strict rules about the open-process, IP arrangements, and >long-term interoperability. > >The entire digital-broadcast and digital-video industry >today is made possible by MPEG-2 technology. This is something >that shouldn't be discounted easily. Part of my goal in >working on synthesis within MPEG was to make flexible >software synthesis into an *industry* rather than a hobby. >If this can be accomplished, the profile of all such tools >will be raised ("a rising tide lifts all boats") and there >will be more attention to be committed to the true advances >in language design such as those represented by SC. > >> Also, far as I can understand SAOL and SC are not really >> competing because they address different problems and levels. >> SAOL is trying to make interactive streaming of synthetic audio >> possible in the context of MPEG4, including combined streaming >> with graphics, as you stated. > >This is true on the surface; however, an underlying goal is to >provide interoperability between MPEG-4 streaming capabilities >and other technology such as PC audio and composing workstations. >I think there's a real possibility to drive forward the whole >PC audio industry around the tools presented in MPEG-4 -- >software synthesis has great application to gaming and other >interactive multimedia as well as art music and compression. > >> SC provides tools for >> musicians/audio designers to create content - it is not a >> technology for "encoding" content destined for transmission or >> reproduction in the strict sense. > >Yes, and a further distinction lies in the development effort. >I often say "a language is not a program" -- a great part of >SC's value lies in the sophisticated interface and systems >interaction that it provides. However, this is not part of >SC qua language but rather a testament to the skill involved >in implementing SC. SAOL, on the other hand, is not a >interface or a "program" but simply a language specification, >in the way that "C" is not a particular compiler. We will >have to wait to see what kinds of tools for musicians >spring up around SAOL. > >> In this sense, it is >> yet unclear to me at what level SAOL/MPEG4 address a) the >> control, b) the modeling and c) the distribution level. > >Only at the specification level. The standard specifies >exactly, given a control signal, how it interacts with a >running SAOL synthesizer. It doesn't say where that control >signal comes from or how it might be used. It doesn't give >any suggestions on good ways to create it. These sorts of >functions are the responsibility of forthcoming (mythical) >SAOL tools. > >The same is true for modeling (if by this you mean instrument >design). The tools are there, and the standard specifies >exactly what they do, but not how or why or when to use them. > >Distribution is a harder question -- we've designed it into >MPEG-4 so that SAOL synthesis can be synchronized, distributed, >broadcasted, and downloaded, but I don't really know whether >this is a useful function. A few experiments -- notably >the suggest of Beatnik -- suggest that it can be if done >right. But there's a lot of underexplored territory in >the use of dynamic sound synthesis in interactive multimedia >transmission. > >> At the control level, there are overlapping interests (goals) >> with OSC and similar schemes. > >I think OSC is more powerful than SASL control of SAOL, >but not so much that cross-coding is impossible. The >important goals of OSC -- remove limits from MIDI arising >from "channels", "notes", and too-narrow bit depth -- are >also met by SASL. > >> At the modeling level there are overlaps with SC on the one hand >> and VRML on the other, although SC seems too high level to serve >> purely as "synthetic sound description" language. Some features >> or ideas in SC might prove of use at this level though. >> Probably it is this level that is the main concern of SAOL and >> where its strengths lie. > >There really isn't much sound modeling in VRML. It's also >useful to keep clearly separate the separate MPEG-4 tools >of SAOL, which is just the synthesis description language, >Structured Audio, which is the whole set of tools for >doing synthesis, and AudioBIFS, which is the set of >nodes in BIFS (the "VRML part" of MPEG-4) allowing >audio mixing, post-production, and synthesis. > >Indeed, many features of SC that are not explored in SAOL >(eg inheritance, real message-passing) would make SAOL >a "better" language in some ways. However, to me they >would also make it a more complicated language, and the >key goal for me has always been to strike a goal between >simplicity and functionality. > >> At the distribution level there is CORBA and DIVE. I am not >> aware of any attempts in MPEG4 to address the problem of >> maintaining consistency of ("synchronizing") replicated objects >> in distributed world models. MPEG4 looks rather oriented towards >> encode-transmit-decode, not towards "communicate commands >> between independent, synchronized worlds". > >Yes, exactly. We want to, but we don't know how. People >from MERL and Sony have been participating to help, but it >didn't get done for V.1 of MPEG-4 and likely won't get done >for V.2. > >> As far as control is concerned, some people I could talk to at >> ICMC98 seemed to think that OSC was lightweight and manageable >> enough to permit low level compatibility at a wide scale while >> leaving the handling of the high level stuff to various synth >> systems like SC. Plus, OSC has public domain code for realizing >> the protocol in your own system, using TCP/IP (UDP?) as >> protocol. > >I think the analogy OSC : SASL :: SC : SAOL is a fine one. >SASL is a control protocol, SAOL is a standard renderer. >There's a working group in MPEG and IETF right now working >on MPEG-4 over IP, btw. (The basic definition of MPEG-4 >is transport-independant -- an API is standardized that >supposedly allows any transport to be used with MPEG-4. >The IP-MPEG4 group is proving this by producing a low-level >stack mapping this API to IP). > >> Then, as far as rendering graphics is concerned, there is >> OpenGL - how does MPEG4 stand to it? > >MPEG-4 is higher level. MPEG-4 provides scene level descriptions >like VRML does, which can be rendered using OpenGL or any other >such system. > >> In other words, SAOL/MPEG4 may be suffering from the confusion >> we had at TEMA about the roles of "content servers" and "design >> environments" on the one hand and "communication codes" on the >> other. > >I think this is a very intriguing point. I view the goal of >MPEG-4 exactly in response to this dichotomy, which I believe >to be false. MPEG-4 is *both* a design representation and a >communication code. (The "environments" for producing designs >in the MPEG-4 representation are non-standard tools which >will come soon). The advantage of unifying the concepts of >"design representation" and "communication code" is flexible >interactivity at the client side. The longer a piece of >content maintains its design representation, the longer >interesting manipulations may be performed upon it. Previous >coding standards have assumed that the design process ends >*before* the content transmission begins; MPEG-4 says in >stead that the content transmission is only part of a >design interaction between the producer and the consumer. > >> One cause of this confusion may be the preoccupation >> with standardizing representation schemes coupled with the need >> to be comprehensive and to provide demonstrator implementations >> of encoders and decoders. Once you set out to solve these you >> end up making the entire application. Perhaps you should be >> "doing less", i.e. instead of defining all the details, rather >> look into how to define your role more clearly in helping to >> fill precisely that demand for integration. > >The problem with this suggestion is that it's a recipe for >disaster in non-working standards. We *have* to make encoders >and decoders so that we can prove (to ourselves, and to >the world) that our standards *work*. This is not to say >that we have limited the space of possible applications >to that of our software, of course. > >> So the pessimistic side of it is that MPEG is so encumbered with >> resolving questions of standards within the industry that it >> does not make progress in providing tools which developers and >> designers want to use right now. > >It is not MPEG's job to provide tools, simply. It is only >MPEG's job to standardize the technology so that tools may >interoperate with each other. If tools do not need >interoperation, they are not living in an MPEG application >space. The whole idea behind SAOL in MPEG-4 is that there >is a need for better interoperability *among* tools than >we currently have, and this problem can only be solved with >standards. I don't think SAOL competes with any particular >tool, but in the long run it may help to improve the >space of all tools for audio. > >Best, > > -- Eric >-- >+-----------------+ >| Eric Scheirer |A-7b5 D7b9|G-7 C7|Cb C-7b5 F7#9|Bb |B-7 E7| >|eds@media.mit.edu| < http://sound.media.mit.edu/~eds > >| 617 253 0112 |A A/G# F#-7 F#-/E|Eb-7b5 D7b5|Db|C7b5 B7b5|Bb| >+-----------------+ > ------------------------------ Date: Wed, 25 Nov 1998 10:17:52 -0600 From: James McCartney <---@---.---> Subject: Re: [fwd] DIVE into mpeg4 At 1:08 PM -0600 11/24/98, Eric Scheirer wrote: >fascinating avenues for discussion. I take your belief >that this topic is not off-topic for the SC as an invitation >to continue. :) Others please complain if this is considered >clutter. continue.. I have two issues with SAOL: 1. It does not seem possible to write SC as a plug in unit generator for it. This is something that I could conceivably do for any other plug in architectures I can think of (TDM, VST, MAS, MAX/MSP, Pd, CSound itself). It relegates everyone to be implementors of a closed standard rather than innovators in an open one. The open standards such as TDM and VST have caused many companies to spring up. I don't see the same thing happening if the standard is closed. 2. I fear that, if successful, it might become the Windows of the synthesis world. I.e. something which is a compromise, has flaws and limitations, but with so much support that all others are marginalized. I can't envision a scenario where the following happens: >If this can be accomplished, the profile of all such tools >will be raised ("a rising tide lifts all boats") and there >will be more attention to be committed to the true advances >in language design such as those represented by SC. The success of C++ did not seem to improve the success of Smalltalk, for example. - -- I also have a suspicion that : SAOL was put into the MPEG4 standard by MIT so that its CSound licensee, Analog Devices, would have a market for that license and a big advantage. And certain features such as requiring sample by sample calculation rather than block calculation would give a big advantage to any DSP based realization over a host CPU based one. (This requirement by the way seems it will make it more difficult for SAOL to take advantage of new vector architectures such as PPC Altivec or Intel Katmai.) --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: ------------------------------ Date: Wed, 25 Nov 1998 12:56:51 -0500 From: Eric Scheirer <---@---.---> Subject: Re: [fwd] DIVE into mpeg4 Hi James, I'm happy to receive your comments on this topic. I know that we have disagreements, but I hope we can air them and all learn from the discussion. > 1. It does not seem possible to write SC as a plug in unit generator for it. > This is something that I could conceivably do for any other plug in > architectures I can think of (TDM, VST, MAS, MAX/MSP, Pd, CSound itself). > It relegates everyone to be implementors of a closed standard rather than > innovators in an open one. The open standards such as TDM and VST > have caused many companies to spring up. I don't see the same thing > happening if the standard is closed. I guess I don't know exactly what "SC as a unit generator" means. To take Csound as an example, how would you embed all of the UI, memory management, etc. functions of SC into the fairly static Csound architecture? How would you embed the Smalltalk- derived syntax of SC into the very simple syntax of Csound? I can see how this might work for more UI-heavy tools such as VST, but Csound (and Max to some degree) each bring their own philosophy which are generally incompatible with the philosophy behind SC. This isn't to say that any of the three philosophies are "wrong", they're just difficult. The same applies in the general language world -- you can't "use Lisp functions in C". You could write a C function which encapsulates a call to an external Lisp interpreter, but I don't think this is the same thing at all. If you mean that it is impossible to write an SAOL program which makes an external call to SC (or indeed anything else), then I agree. But this is part of the necessity of interoperability -- what would I do with such a composition on a platform that didn't have SC? (Of course, it is "possible" to write an SC interpreter in SAOL as SAOL and other music languages are Turing-complete, but this is a silly theoretical argument without much practical significance). > 2. I fear that, if successful, it might become the Windows of the > synthesis world. > I.e. something which is a compromise, has flaws and limitations, but with > so much support that all others are marginalized. I think it would be horrible if this occurred. The important aspect to me is that SAOL has no user-interface concepts or goals at all. In order to make tools for musicians around SAOL, sophisticated *musical* tools must be developed. For example, it's easy for me to imagine a SC->SAOL translator (since SAOL is simpler than SC). In this way, SC and all of the important concepts it embodies simply run on top of SAOL. > I can't envision a scenario where the following happens: > > >If this can be accomplished, the profile of all such tools > >will be raised ("a rising tide lifts all boats") and there > >will be more attention to be committed to the true advances > >in language design such as those represented by SC. What if (to take an example), the common sound card for a PC 10 years from now has a massively parallel array of DSPs that runs SAOL in real time at 100 GFlops and 1 ms latency, with easy APIs for communicating in SAOL with the card. Wouldn't this be a useful platform to write SC on top of? That is, keeping the Smalltalk "look and feel" of the SC tool, but rather than doing the synthesis yourself, compiling it into SAOL and mailing it to this high-performance sound card. And then SC could be easily ported to any system which had such sound cards. This, to me, represents the best of both worlds: "look and feel" experts who know how to present an interface to users can work on those aspects, while industry works hard to create a more robust and useful substrate of audio-synthesis tools. > > The success of C++ did not seem to improve the success of Smalltalk, > for example. Smalltalk is a funny example, since it's been around so long. But I bet the success of C++ *has* opened up more opportunities for research into new message-passing and OO models. Certainly, today the world of "normal" audio coding research has a much better understanding of the power of general-purpose software synthesis than they did two years ago. > I also have a suspicion that : > > SAOL was put into the MPEG4 standard by MIT so that its CSound licensee, > Analog Devices, would have a market for that license and a big advantage. > And certain features such as requiring sample by sample calculation rather > than block calculation would give a big advantage to any DSP based > realization over a host CPU based one. > (This requirement by the way seems it will make it more difficult for SAOL > to take advantage of new vector architectures such as PPC Altivec or > Intel Katmai.) I'm glad you articulated this suspicion, because I'm sure others have had it as well, and it's good to have in the open. I want to say clearly that, at least from my point of view, there has not been any such goal in this work. I have never worked or consulted for ADI, and have never owned stock or had any other financial connection to them. I've never signed an NDA with them. The connections between people (Prof. Vercoe especially) who *do* stand to gain from the ADI-Csound project and the SAOL project are tenuous -- I have personally done at least 95% of the work on both the code and the specification, and I don't think that any of the other 5% came from anyone with ties to ADI. About the strongest statement that could be true is that Prof. Vercoe, as my advisor, approved my spending two years working on this project. Perhaps (or perhaps not) his involvement with ADI had something to do with that. But his involvement ends there. In fact, I am not a big fan of the ADI-Csound project (although I don't know anything more about it than any other interested independent developer). I certainly don't think compile-to- Csound is the best way to implement SAOL. I have told this to other companies that have asked my opinion on MPEG-4 tools development. In some abstract sense, I suppose the "expertise" that ADI has developed in the Csound project could give them a leg up, but to me their track record on the project is not indicative of expertise. In fact, as you say, certain features of SAOL (eg sample-by-sample semantics) would make it very difficult to implement SAOL in Csound. I have rejected the idea of re-using Csound source to write the SAOL reference software explicitly for the goal of maintaining separation between these projects. SAOL is only "like Csound" insofar as (a) it's the style of music programming I know best, and (b) I think it's the style of music programming with which the majority of composers are most comfortable. SAOL departs from the Csound approach in many ways, and almost all of these in directions that make SAOL-to-Csound translation difficult. Finally, I note that it would have been easy (and was desired by many here) to pursue patentable IP within MPEG-4 and stake out MIT patent territory in the world of music-synthesis. I have repeatedly rejected this idea in favor of immediately open-sourcing every piece of work I've done. I have had to fight significant political battles at MIT in order to accomplish this, as MPEG standards can be a great revenue source for IP owners. There is no way in which I, or MIT, stands to directly profit from the standardization of the MPEG-4 Structured Audio tools, or from their acceptance by a broad community. Of course I hope to someday be able to make money consulting about the standard, but given other noted instutions' attitude in favor of aggressively patenting computer-music technology, I think my motives, and MIT's motives, are unimpeachable on this front. With regard to DSP-centrism, I do plead guilty there -- I believe that using DSP accelerators for sound, just as today we use polygon accelerators for 3-D graphics, is the way towards a better future in PC audio. Note, though, that there is no requirement that the processing occur sample- by-sample -- it is rather that the *semantics* of the SAOL code are defined sample-by-sample. The spec is specifically written to support the development of vectorizing compilers which statically detect when it is possible to do block processing and get the same result. The semantics are sample-by-sample simply because there's some constructs that are useful to musicians that can't be achieved in block- based semantics. Thanks again for your thoughts, and I'd be very interested to read a response to what I've written. Best, -- Eric - -- +-----------------+ | Eric Scheirer |A-7b5 D7b9|G-7 C7|Cb C-7b5 F7#9|Bb |B-7 E7| |eds@media.mit.edu| < http://sound.media.mit.edu/~eds > | 617 253 0112 |A A/G# F#-7 F#-/E|Eb-7b5 D7b5|Db|C7b5 B7b5|Bb| +-----------------+ ------------------------------ Date: Wed, 25 Nov 1998 14:05:56 -0600 From: James McCartney <---@---.---> Subject: Re: [fwd] DIVE into mpeg4 At 11:56 AM -0600 11/25/98, Eric Scheirer wrote: >I guess I don't know exactly what "SC as a unit generator" means. >To take Csound as an example, how would you embed all of the >UI, memory management, etc. functions of SC into the fairly >static Csound architecture? How would you embed the Smalltalk- >derived syntax of SC into the very simple syntax of Csound? >I can see how this might work for more UI-heavy tools such as >VST, but Csound (and Max to some degree) each bring their own >philosophy which are generally incompatible with the philosophy >behind SC. SC began as Pyrite, a MAX plug in. SC could be embedded in CSound as a single unit generator that ran an SC program to process its inputs and outputs. It could be a separate world inside CSound. I'm not saying this is a logical design, but it is a possible one. >If you mean that it is impossible to write an SAOL program which >makes an external call to SC (or indeed anything else), then I >agree. Precisely. Without the ability of Arboretum, Waves, or Bitheads, etc to write SAOL plug ins you lose a lot of interest from vendors. I think SAOL addresses something which no other part of MPEG does and that is content creation tools, not just a content transmission medium. But the problem is that it defines a restricted set of techniques and that is not in the nature of content creation as it is in content transmission. SAOL in effect becomes another General MIDI. More capable than GM, but still with its own ceiling. >I think it would be horrible if this occurred. The important >aspect to me is that SAOL has no user-interface concepts or >goals at all. In order to make tools for musicians around >SAOL, sophisticated *musical* tools must be developed. For >example, it's easy for me to imagine a SC->SAOL translator >(since SAOL is simpler than SC). In this way, SC and all of the >important concepts it embodies simply run on top of SAOL. That is not possible with the design of SAOL as I understand it. SC IS NOT a user interface for a synth engine.(see below) >> I can't envision a scenario where the following happens: >> >> >If this can be accomplished, the profile of all such tools >> >will be raised ("a rising tide lifts all boats") and there >> >will be more attention to be committed to the true advances >> >in language design such as those represented by SC. >What if (to take an example), the common sound card for a PC >10 years from now has a massively parallel array of DSPs that >runs SAOL in real time at 100 GFlops and 1 ms latency, with >easy APIs for communicating in SAOL with the card. >Wouldn't this be a useful platform to write SC on top of? That Then I'll be in the same situation as the Smalltalk folks who are trying to figure out how to run Smalltalk on top of a Java VM. Trying to fit a round peg in a square hole. >This, to me, represents the best of both worlds: "look and >feel" experts who know how to present an interface to users >can work on those aspects, while industry works hard to >create a more robust and useful substrate of audio-synthesis >tools. SC is not a look and feel on top of a synth engine. It is the answer to a set of design decisions: That the highest level algorithmic processes can be applied to signal processing structures in real time and that signal level events can call high level code. In SC I can create a new instrument algorithmically, per event. "parameters" in my score can be patches that plug into the "instrument" to create a unique structure for that event only. Series and parallel chains of unit generators can be made arbitrary lengths per event. SAOL represents a DSP structure with code. SC represents a DSP structure as data, and the SC code when called builds that structure. If SAOL is embedded in a card and I have to use it to create an algorithm, then it is useless to me because with SC there are no set instrument algorithms until an event occurs. >(b) I think it's the >style of music programming with which the majority of >composers are most comfortable. Maybe only because for so long it was the only one available. I'd say your environment may skew your perspective as well. The majority seem to find MAX the most comfortable. >processing and get the same result. The semantics are >sample-by-sample simply because there's some constructs >that are useful to musicians that can't be achieved in block- >based semantics. What about variable block sizes (e.g. including 1)? SC allows each event to have a separate block size. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: ------------------------------ Date: Wed, 25 Nov 1998 16:35:03 -0500 From: Eric Scheirer <---@---.---> Subject: Re: [fwd] DIVE into mpeg4 James McCartney wrote: > > SC began as Pyrite, a MAX plug in. > SC could be embedded in CSound as a single unit generator that > ran an SC program to process its inputs and outputs. It could > be a separate world inside CSound. I'm not saying this is a logical > design, but it is a possible one. Well, to me there is a useful distinction between "logical" and "possible". It *is* logically possible to embed SC within SAOL: you write a user-defined unit generator which accepts a wavetable as a parameter. This wavetable contains the ASCII values of a SC program. The unit generator compiles and executes the SC program. The output of the SC program is the output of the SAOL unit generator. This is provably possible since SAOL is Turing-complete. It is not useful or practical. Is it useful or practical to "embed" SC inside Csound? I run Csound on SGI -- don't I then have to network to a PowerMac to practically accomplish the embedding? I'm not sure there's any use to an argument comparing relative degrees of impracticality... It is impractical to embed SC within Csound, just as it is impractical to embed SC within SAOL. This doesn't hurt the popularity of Csound. The important aspect of extensibility in Csound is the ability of the community to author new unit generators and evolve the language base. This capability is preserved in SAOL by having a richer model for user-defined unit generators. Does SC itself have a plugin API? > Precisely. Without the ability of Arboretum, Waves, or Bitheads, etc > to write SAOL plug ins you lose a lot of interest from vendors. > I think SAOL addresses something which no other part of MPEG does and > that is content creation tools, not just a content transmission medium. > But the problem is that it defines a restricted set of techniques and > that is not in the nature of content creation as it is in content > transmission. SAOL in effect becomes another General MIDI. > More capable than GM, but still with its own ceiling. No. GM is not Turing-complete, SAOL is. This is a difference of type, not of magnitude. You can do *anything* in SAOL, or at least do any kind of synthesis. It might be easier to do some particular task in some other language, but it is possible to do everything in SAOL. (The space of "everything" defined as the set of mappings from control sequences to sound output). In this sense, SAOL has the same ceiling as Csound, SC, Nyquist, and every other general-purpose synthesis language. > >What if (to take an example), the common sound card for a PC > >10 years from now has a massively parallel array of DSPs that > >runs SAOL in real time at 100 GFlops and 1 ms latency, with > >easy APIs for communicating in SAOL with the card. > >Wouldn't this be a useful platform to write SC on top of? That > > Then I'll be in the same situation as the Smalltalk folks who are > trying to figure out how to run Smalltalk on top of a Java VM. > Trying to fit a round peg in a square hole. But of course it is *possible* to run Smalltalk in a Java VM. And if Java VMs were a thousand times faster than they are, and 100 times faster than other ways of accessing machine resources, then it would be a more useful thing to try to make work. Even if you didn't want to compile to SAOL, the capabilities such hardware would need (very low latency, advanced programmability) would surely be useful for other kinds of audio programming. > >This, to me, represents the best of both worlds: "look and > >feel" experts who know how to present an interface to users > >can work on those aspects, while industry works hard to > >create a more robust and useful substrate of audio-synthesis > >tools. > > SC is not a look and feel on top of a synth engine. > It is the answer to a set of design decisions: > That the highest level algorithmic processes can be applied to > signal processing structures in real time and that signal level > events can call high level code. In SC I can create > a new instrument algorithmically, per event. "parameters" in > my score can be patches that plug into the "instrument" to > create a unique structure for that event only. Series and > parallel chains of unit generators can be made arbitrary lengths > per event. > > SAOL represents a DSP structure with code. SC represents a DSP > structure as data, and the SC code when called builds that structure. > If SAOL is embedded in a card and I have to use it to create an > algorithm, then it is useless to me because with SC there are no > set instrument algorithms until an event occurs. There are two arguments here that I think you're confusing. (1) There are some things (some kinds of synthesis, or some kind of control structure) which are possible in SC, but not in SAOL. (2) There are some things which are nicer to do in SC than in SAOL. (1) is false. There is nothing possible in SC that is impossible in SAOL. (2) is certainly true. SC is a better language than SAOL in many regards, and I have said so in print. But it's better in the sense of "nicer to the programmer", not "more powerful theoretically". This is what I meant by "look and feel". The differences between C, Pascal, APL, Lisp, Smalltalk, and Eiffel are only "look and feel" in the same way. For example, I can write a SAOL instrument like: instr patch(p1, p2, ...) { asig a1, a2, ... a1 = oscil(...); if (p1 == 1) { a2 = aline(...) * a1; } else if (p1 == 2) { a2 = oscil(...) * a1; } else if (p1 == 3) { a2 = oscil(...,a1); } else ... if (p2 == 1) { a3 = aline(...) * a2; } else if (p2 == 2) { a3 = oscil(...) * a2; } else if (p1 == 3) { a3 = oscil(...,a1); } ... output(a20); } that is, it does "dynamic patching" of a bunch of oscillators and line segments based on a set of parameters. There is no instrument that uses the dynamic patching capabilities of SC that cannot be easily converted (albeit with exponentially growing time and space multipliers for the "most obvious" conversion) into a SAOL instrument of this sort. > Maybe only because for so long it was the only one available. > I'd say your environment may skew your perspective as well. > The majority seem to find MAX the most usable. I take all of these points. Time will tell. In the long run, I hope the answer *is* SC or something else as expressive and useful. But I think SAOL is a valuable intermediate step to demonstrate the utility of general- purpose software synthesis to a broader community. The audio coding and audio hardware people like SAOL. The MIDI people can tolerate SAOL. It has been a lot of political work to get to that point. If you and I don't like SAOL quite as much as we do other languages, it's still better than the situation pre-MPEG-4, which is MIDI or nothing as far as most of the world is concerned. I'll note that the first draft of MPEG-4 (before we started participating) simply embedded GM and DLS in MPEG-4 as the international standard for synthetic sound. I hope that wouldn't make you any happier! > >processing and get the same result. The semantics are > >sample-by-sample simply because there's some constructs > >that are useful to musicians that can't be achieved in block- > >based semantics. > > What about variable block sizes (e.g. including 1)? > SC allows each event to have a separate block size. This only increases efficiency, not expressivity. A good compiler could do the same thing. Separate block sizes could be viewed as a #pragma to give the compiler a hint about what's going on. There is nothing you can do in block size > 1 that you can't do with block size 1. (The converse is not true). On a separate point, I was disappointed that you chose not to respond to my defense of my and MIT's motives in pursuing this work. Does that mean you were convinced, or that you simply don't believe me? Best, -- Eric - -- +-----------------+ | Eric Scheirer |A-7b5 D7b9|G-7 C7|Cb C-7b5 F7#9|Bb |B-7 E7| |eds@media.mit.edu| < http://sound.media.mit.edu/~eds > | 617 253 0112 |A A/G# F#-7 F#-/E|Eb-7b5 D7b5|Db|C7b5 B7b5|Bb| +-----------------+ ------------------------------ Date: Wed, 25 Nov 1998 20:10:42 -0600 From: James McCartney <---@---.---> Subject: Re: [fwd] DIVE into mpeg4 >you write a user-defined unit generator which accepts a wavetable >as a parameter. This wavetable contains the ASCII values of >a SC program. OK. So that addresses my point 1. When I asked if unit generators were loadable at ICMC you said no. >I run Csound on SGI -- don't I >then have to network to a PowerMac to practically accomplish >the embedding? SC is portable at least in theory at this point. >It is impractical to embed SC within Csound I don't see why. I have no reason to do so in CSound, but I may have a reason to write SC as a plug in to VST or Pd. >(1) is false. There is nothing possible in SC that is impossible >in SAOL. ... >There >is no instrument that uses the dynamic patching capabilities >of SC that cannot be easily converted (albeit with >exponentially growing time and space multipliers for the >"most obvious" conversion) into a SAOL instrument of this sort. That something may be theoretically possible in a language but not practically acheivable is of no value. If SC can do something in real time that would require hugely inefficient coding in SAOL does no one any good that it is still "possible". Turing completeness is meaningless in the face of a constraint like 'must run in real time'. To do any symbolic operations in SAOL one would have to write a virtual machine in SAOL, so Turing completeness is pretty useless there too. No normal person will attempt it. >On a separate point, I was disappointed that you chose not >to respond to my defense of my and MIT's motives in pursuing >this work. Does that mean you were convinced, or that you >simply don't believe me? I accepted your explanation. I threw that up as a straw man for you to knock down because I wanted to get your scoop on it. --- james mccartney james@audiosynth.com http://www.audiosynth.com If you have a PowerMac check out SuperCollider2, a real time synth program: ------------------------------ End of sc-users-digest V1 #16 *****************************