From: owner-sc-users-digest@lists.io.com (sc-users-digest) To: sc-users-digest@lists.io.com Subject: sc-users-digest V1 #15 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 Tuesday, November 24 1998 Volume 01 : Number 015 ---------------------------------------------------------------------- Date: Mon, 23 Nov 1998 10:33:30 -0800 From: Mark Polishook <---@---.---> Subject: GUI question Given this snippet.... //***** SliderView.new( // control freq w, // window Rect.newBy(20, 36, 160, 16), nil, 440, 440, 880, 0, 'linear').mapToController(0, 0); //***** What do the 'nil' and the '0' control? TIA, Mark here's the same code in context ////////////////////////////////////////////////////////////////////////// // 2 sliders to control FREQ and AMP of a sine wave ( w = GUIWindow.new("Sine Wave", Rect.newBy(40,80,200,100)); SliderView.new( // control freq w, // window Rect.newBy(20, 36, 160, 16), nil, 440, 440, 880, 0, 'linear').mapToController(0, 0); SliderView.new( // control amp w, // window Rect.newBy(20, 56, 160, 16), nil, 0.5, 0.1, 1, 0, 'linear').mapToController(0, 0); { var freq, amp; freq = ControlIn.kr(w.at(0)); amp = ControlIn.kr(w.at(1)); SinOsc.ar(freq, 0, amp); }.play; w.close; ) * * * * * * * * Mark Polishook Assistant Professor of Composition Music Department Central Washington University Ellensburg, WA 98926 tel.: 509-963-1245 fax: 509-963-1239 e-mail: polishoo@cwu.edu http://www.cwu.edu/~music/composition ------------------------------ Date: Tue, 24 Nov 1998 09:52:06 +1100 From: ggerrard <---@---.---> Subject: Re: SC->ADAT Thanks for your response Iannis. I have followed the instructions in the 1212 manual and in the html file that came with the 1212. I have been able to get audio out from SC if I change the Sound Manager Routing settings in the i/o utility, so that the L & R Outputs go to the ADAT 1 & 2, but not directly, i.e. bypassing the sound manager. >Which mixer do you use and how do you configure it to send >the 8 channels out separately? Any additional effects >or mixing you intend to do? Would be interested to hear >about this if its not a trade secret... I have an Allen & Heath WZ16:2. It has 16 in and 16 direct outs, 8 of which I send to my speakers. These are post EQ, post fader. I am not using outboard effects (though I could thru the inserts on each channel if I wanted). I am essetially using the mixer to control individual levels to the speakers. Another way to go would be an 8 bus mixer. This would be a more typical use of a mixer, mixing your input channels to the buses, and connect the 8 buses to speakers directly. But 8-bus mixers of any quality are more expensive. Digital mixers like the 01v, 03D don't have enough ANALOG outputs. (The 02R does, but that was a little out of my price range!) - --------------- Graeme Gerrard Resonant Multimedia ph. 03 9525 7869 mob 0419 396 754 "Somebody's been putting something in my food to make me paranoid." - PKD ------------------------------ Date: Tue, 24 Nov 1998 14:19:31 +1100 From: ggerrard <---@---.---> Subject: Re: SC->ADAT I managed to get this working fine now. What I hadn't done was remove the Sound Control Panel replacement that comes with the 1212 i/o. Maybe it is not necessary under 8.5? Who knows? But now I have 8 beautiful channels coming digitally out of SC into the ADAT. That's step one. Now, down to business. Graeme Gerrard "Back off man, I'm a scientist!" Resonant Multimedia - Bill Murray!!! 03 9525 7869 ------------------------------ Date: Tue, 24 Nov 1998 07:55:32 -0600 From: James McCartney <---@---.---> Subject: [fwd] DIVE into mpeg4 This bounced because you are subscribed as ken@limbo.create.ucsb.edu not ken@create.ucsb.edu... >Subject: BOUNCE sc-users@lists.io.com: Non-member submission from [kf Oe ] >Date: Tue, 24 Nov 1998 00:43:13 +0000 >From: kf Oe <---@---.---> >Subject: DIVE into mpeg4 > >While trying to stick to the SC list topic: > >http://garuda.imag.fr/MPEG4/syssite/syspub/index.html > >I don't understand this fully. but, DIVE is not the >only avenue developing distributed, interactive >systems. the vrml and (specifically) the vrml/mpeg4 >working groups have been thinking about this. > >There are many diverse goals in using >3D graphic environments in conjuction with >the sound synthesis environment. One goal is >controllers. Another may be to trigger/guide >entire sound tracks. Another goal might be >a very fancy GUI to the sound programming >environment. Another is simply the sound/concert >listening space of choice (immersed). > >Further removed: >What about sending sound control parameters >within a stream of 2D video, such as a quicktime >midi movie playing your SC. > >I guess the main point is just the Open Sound >Control possibility; to communicate more directly >to variable inputs from various sources -- on the >mac or from another machine. > >Anyway, in trying to write a piece with 3D graphics >I find myself going back to the old paradigm of >preparing soundfiles and putting them in the sound >track area. This is what real-time, interactive >synthesis/processing is supposed to cure. > >ken. > ------------------------------ Date: Tue, 24 Nov 1998 09:31:09 -0500 From: Eric Scheirer <---@---.---> Subject: Re: [fwd] DIVE into mpeg4 [ This is not really on-topic, but I thought I'd post some pointers. Anyone who wants more details can contact me directly or see our WWW site at ] > >http://garuda.imag.fr/MPEG4/syssite/syspub/index.html (This is a pointer to the MPEG-4 "Systems" site. MPEG-4 Systems, among other things, allows the description of virtual worlds with integrated streaming media, interaction, and downloadable audio/video post-processing. It will ship as a document in January, and many companies are already starting development). > >I don't understand this fully. but, DIVE is not the > >only avenue developing distributed, interactive > >systems. the vrml and (specifically) the vrml/mpeg4 > >working groups have been thinking about this. Yes. But particularly with regard to "distributed", this is not very advanced thinking yet -- both MPEG and VRML have wanted to develop more robust standards for distributed virtual worlds, but haven't gotten very far yet. Interaction is another story, interaction models are quite well developed now. > >There are many diverse goals in using > >3D graphic environments in conjuction with > >the sound synthesis environment. One goal is > >controllers. Another may be to trigger/guide > >entire sound tracks. Another goal might be > >a very fancy GUI to the sound programming > >environment. Another is simply the sound/concert > >listening space of choice (immersed). All of this is already being standardized in MPEG-4. Plus synchronization and merging of synthesis and compressed streaming sound (like voice tracks). > >Further removed: > >What about sending sound control parameters > >within a stream of 2D video, such as a quicktime > >midi movie playing your SC. This is also standardized in MPEG-4. > >Anyway, in trying to write a piece with 3D graphics > >I find myself going back to the old paradigm of > >preparing soundfiles and putting them in the sound > >track area. This is what real-time, interactive > >synthesis/processing is supposed to cure. And this is one of the basic goals of MPEG-4, which I believe it solves. Finally, I note that it's not right for me to use this forum to "advertise" MPEG-4, especially since I know that important people in the SC community (all the way up to the developer) have serious misgivings about the whole project. I'd welcome public response from anyone who wishes to comment or criticize on the direction of work and the standards progress of MPEG-4. I won't post any more here. The web site listed above has links to mailing lists for discussion of synthesis in MPEG-4. -- Eric Editor, MPEG-4 Audio - -- +-----------------+ | 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: Tue, 24 Nov 1998 18:51:45 +0100 From: "Iannis Zannos" <---@---.---> Subject: Re: [fwd] DIVE into mpeg4 Eric, >This is not really on-topic, but I thought I'd post > ... your message is not altogether off-topic. It is fair to look into other directions to see what is happening there, if anything to improve on work at hand. >... I'd welcome public response from anyone who >wishes to comment or criticize on the direction of work >and the standards progress of MPEG-4. 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. At TEMA (a small EU research project) we had been looking into MPEG-4 in some detail while planning for phase2 (which did not happen, by the way). That is where the comparison SC - MPEG4 (SAOL) - MIDAS took place. We thought that SAOL was too encumbered by its lineage (CSound, orchestra-score model), and by the inherent complexity of MPEG - which has its own lineage and has to cater for disparate media needs and a very wide range of technologies. I am aware of the talk about making SAOL object oriented some time ago on the related list. The bottom of the line is, I think that computer musicians and related artists/designers want something that is easy to handle, gives them much freedom to realize their creative ideas, plus recently are increasingly out for fundamentally and thoroughly interactive capabilities. (may be likened to "quality"). 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 am otherwise aware of the considerable amount of work that went into opening avenues for interactivity in SAOL. 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. 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. To try and exchange or equate the roles of MPEG4-SAOL and SC would be a misguided and senseless attempt at misuse. I think we were trying to do this at TEMA, without being aware of it. What was learned, if anything, was that there are different places for these things, and also that it helps to keep them apart. 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. At the control level, there are overlapping interests (goals) with OSC and similar schemes. 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. 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". So, perhaps SAOL/MPEG4 should sort out where it stands regarding the three tasks above and the tools available for them at the moment. In that light it would be easier to discuss along the lines of your posting: > Yes. But particularly with regard to "distributed", this > is not very advanced thinking yet -- both MPEG and > VRML have wanted to develop more robust standards for > distributed virtual worlds, but haven't gotten very > far yet. Interaction is another story, interaction > models are quite well developed now. If MPEG4 can define its place clearly in the above context and make further progress in providing the required implementations, then it could be the required link for integrating audio, graphic, and interaction. This would mean having MPEG4 drivers that can be integrated for example in SC to communicate with graphics servers, controllers, and world model database servers. 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. But SAOL also is a kind of standardized "renderer". Synthesizer hardware builders may want to use it in the future, musicians users prefer the ready to use tools available in SC now. Then, as far as rendering graphics is concerned, there is OpenGL - how does MPEG4 stand to it? 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. 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. 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. The other side of it is that the demand for integrating audio, animated graphics and interaction in networked components is very strong as the postings by Staffan, Ken et al. here show. MPEG4 is indeed the one place where gigantic efforts are being done in this direction. So we are still expecting some useful solutions to come from there. It may help if you define your role more clearly to meet precisely that demand for an integrating communication medium, by linking with other existing "content servers" and "design environments" rather than trying to achieve all three of the tasks within MPEG4. If the integration has been achieved already or is about to come and we can use it in the context of SC connecting to graphics and world database engines, it would sure be an exciting thing - do let people know here. 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 3:31 PM > >[ >This is not really on-topic, but I thought I'd post >some pointers. Anyone who wants more details can >contact me directly or see our WWW site at > >] > >> >http://garuda.imag.fr/MPEG4/syssite/syspub/index.html > >(This is a pointer to the MPEG-4 "Systems" site. MPEG-4 >Systems, among other things, allows the description of >virtual worlds with integrated streaming media, interaction, >and downloadable audio/video post-processing. It will >ship as a document in January, and many companies are >already starting development). > >> >I don't understand this fully. but, DIVE is not the >> >only avenue developing distributed, interactive >> >systems. the vrml and (specifically) the vrml/mpeg4 >> >working groups have been thinking about this. > >Yes. But particularly with regard to "distributed", this >is not very advanced thinking yet -- both MPEG and >VRML have wanted to develop more robust standards for >distributed virtual worlds, but haven't gotten very >far yet. Interaction is another story, interaction >models are quite well developed now. > >> >There are many diverse goals in using >> >3D graphic environments in conjuction with >> >the sound synthesis environment. One goal is >> >controllers. Another may be to trigger/guide >> >entire sound tracks. Another goal might be >> >a very fancy GUI to the sound programming >> >environment. Another is simply the sound/concert >> >listening space of choice (immersed). > >All of this is already being standardized in MPEG-4. Plus >synchronization and merging of synthesis and compressed >streaming sound (like voice tracks). > >> >Further removed: >> >What about sending sound control parameters >> >within a stream of 2D video, such as a quicktime >> >midi movie playing your SC. > >This is also standardized in MPEG-4. > >> >Anyway, in trying to write a piece with 3D graphics >> >I find myself going back to the old paradigm of >> >preparing soundfiles and putting them in the sound >> >track area. This is what real-time, interactive >> >synthesis/processing is supposed to cure. > >And this is one of the basic goals of MPEG-4, which I >believe it solves. > >Finally, I note that it's not right for me to use this >forum to "advertise" MPEG-4, especially since I know that >important people in the SC community (all the way up to >the developer) have serious misgivings about the whole >project. I'd welcome public response from anyone who >wishes to comment or criticize on the direction of work >and the standards progress of MPEG-4. > >I won't post any more here. The web site listed above >has links to mailing lists for discussion of synthesis >in MPEG-4. > > -- Eric > Editor, MPEG-4 Audio > >-- >+-----------------+ >| 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: Tue, 24 Nov 1998 14:08:38 -0500 From: Eric Scheirer <---@---.---> Subject: Re: [fwd] DIVE into mpeg4 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: Tue, 24 Nov 1998 11:31:18 +0000 From: kf Oe <---@---.---> Subject: DIVE into mpeg4 While trying to stick to the SC list topic: http://garuda.imag.fr/MPEG4/syssite/syspub/index.html I don't understand this fully. but, DIVE is not the only avenue developing distributed, interactive systems. the vrml and (specifically) the vrml/mpeg4 working groups have been thinking about this (among others). There are many diverse goals in using 3D graphic environments in conjuction with the sound synthesis environment. One goal is controllers. Another may be to trigger/guide entire sound tracks. Another goal might be a very fancy GUI to the sound programming environment. Another is simply the sound/concert listening space of choice (immersed). Further removed: What about sending sound control parameters within a stream of 2D video, such as a quicktime midi movie playing your SC. I guess the main point is just the Open Sound Control possibility; to communicate more directly to variable inputs from various sources -- on the mac or from another machine. Anyway, in trying to write a piece with 3D graphics I find myself going back to the old paradigm of preparing soundfiles and putting them in the sound track area. This is what real-time, interactive synthesis/processing is supposed to cure. ken. ------------------------------ Date: Tue, 24 Nov 1998 12:58:29 +0000 From: kf Oe <---@---.---> Subject: Re: [fwd] DIVE into mpeg4 >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. I'm happy with the discussion. Why are the people on this list here in the first place? SC provides the ability to work in REAL-TIME (almost!). VRML provides this also (almost). One has to of course, design (or potentialize) the sound/world first, and the rules of that world. But then it is a sound/world to be explored. >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. This is interestingly put.... except terms "producer/consumer" imply a pretty boring "interactivity." Just looking on the amusing side of things for a moment. Though I am aware that most people want nothing more than to be passively educated/entertained/enlightened/created. ken. ------------------------------ Date: Tue, 24 Nov 1998 15:50:25 -0600 From: antiorp@tezcat.com (=cw4t7abs) Subject: Re: [fwd] DIVE into mpeg4 >I'm happy with the discussion. Why are the people on this >list here in the first place? Why are the people in the first place? >SC provides the ability provides the ability - shrtkut 2 elektr!s!t! !n dze m9nd konta!nr >to work >in REAL-TIME (almost!). REAL-TIME != ecz!zt > VRML shrtkut 2 elektr!s!t! !n dze m9nd konta!nr > >Previous >>coding standards have assumed that the design process ends >>*before* the content transmission begins; shrtkut 2 anal!s!z >MPEG-4 says in >>stead that the content transmission is only part of a >>design interaction between the producer and the consumer. shrtkut 2 anal!s!z >This is interestingly put.... except terms "producer/consumer" >imply a pretty boring "interactivity." "interactivity." = korrekt. >Just looking on the >amusing side of things for a moment. Though I am aware >that most people want nothing more than to be passively >educated/entertained/enlightened/created. az opzd 2 + "interactivity." prm!t zom1 2 zm!le at dze `amusing side of things for a moment` ------------------------------ Date: Tue, 24 Nov 1998 15:52:10 -0600 From: antiorp@tezcat.com (=cw4t7abs) Subject: Re: cure. >This is what real-time, interactive >synthesis/processing is supposed to cure. p z 2 v cure++ ------------------------------ Date: Tue, 24 Nov 1998 16:46:51 -0500 From: Eric Scheirer <---@---.---> Subject: Re: [fwd] DIVE into mpeg4 kf Oe wrote: > This is interestingly put.... except terms "producer/consumer" > imply a pretty boring "interactivity." Just looking on the > amusing side of things for a moment. Though I am aware > that most people want nothing more than to be passively > educated/entertained/enlightened/created. Heh. s/producer/artist/g s/consumer/engaged, knowledgable audience/g Better? -- 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: Tue, 24 Nov 1998 17:09:27 -0600 From: antiorp@tezcat.com (=cw4t7abs) Subject: Re: [fwd] DIVE into mpeg4 >kf Oe wrote: >> This is interestingly put.... except terms "producer/consumer" >> imply a pretty boring "interactivity." Just looking on the >> amusing side of things for a moment. Though I am aware >> that most people want nothing more than to be passively >> educated/entertained/enlightened/created. > >Heh. mpeg4 >s/producer/artist/g >s/consumer/engaged, knowledgable audience/g > >Better? $_ = "artist consumer"; s/artist/modl_citizen\=/g; s/consumer/artist/g; foreach ($_){print "$_\n";} \ \ besser.konsumerz. \ ------------------------------ Date: Tue, 24 Nov 1998 16:30:53 -0800 From: Mark Polishook <---@---.---> Subject: gui quesion I'm hoping that someone could clarify...in the SliderView snippet below, what paramter is controlled by 'nil? And what parameter is controlled by '0?" //***** SliderView.new( // control freq w, // window Rect.newBy(20, 36, 160, 16), nil, 440, 440, 880, 0, 'linear').mapToController(0, 0); //***** TIA, Mark - --here's the same code in context ////////////////////////////////////////////////////////////////////////// // 2 sliders to control FREQ and AMP of a sine wave ( w = GUIWindow.new("Sine Wave", Rect.newBy(40,80,200,100)); SliderView.new( // control freq w, // window Rect.newBy(20, 36, 160, 16), nil, 440, 440, 880, 0, 'linear').mapToController(0, 0); SliderView.new( // control amp w, // window Rect.newBy(20, 56, 160, 16), nil, 0.5, 0.1, 1, 0, 'linear').mapToController(0, 0); { var freq, amp; freq = ControlIn.kr(w.at(0)); amp = ControlIn.kr(w.at(1)); SinOsc.ar(freq, 0, amp); }.play; w.close; ) * * * * * * * * Mark Polishook Assistant Professor of Composition Music Department Central Washington University Ellensburg, WA 98926 tel.: 509-963-1245 fax: 509-963-1239 e-mail: polishoo@cwu.edu http://www.cwu.edu/~music/composition * * * * * * * * Mark Polishook Assistant Professor of Composition Music Department Central Washington University Ellensburg, WA 98926 tel.: 509-963-1245 fax: 509-963-1239 e-mail: polishoo@cwu.edu http://www.cwu.edu/~music/composition ------------------------------ Date: Tue, 24 Nov 1998 21:20:38 -0500 (EST) From: "Colby N. Leider" <---@---.---> Subject: Re: gui quesion hi, check out the code below... // 2 sliders to control FREQ and AMP of a sine wave ( w = GUIWindow.new("Sine Wave", Rect.newBy(40,80,200,100)); SliderView.new( // control freq w, // window Rect.newBy(20, 36, 160, 16), 'dweeb', // slider label 440, // initial value 440, // slider min 880, // slider max 0, // increment = epsilon 'linear' ).mapToController(0, 0); SliderView.new( // control amp w, // window Rect.newBy(20, 56, 160, 16), 'doobage', // slider label 0.1, // initial value 0.01, // slider min 0.3, // slider max 0.1, // increment 'linear' ).mapToController(0, 0); { var freq, amp; freq = ControlIn.kr(w.at(0)); amp = ControlIn.kr(w.at(1)); w.at(0).label.postln; w.at(1).label.postln; SinOsc.ar(freq, 0, amp); }.play; w.close; ) - --- this is from the ControlView class: ControlView : View { var I'm hoping that someone could clarify...in the SliderView snippet below, > what paramter is controlled by 'nil? And what parameter is controlled by > '0?" > > //***** > SliderView.new( // control freq > w, // window > Rect.newBy(20, 36, 160, 16), > nil, 440, 440, 880, 0, 'linear').mapToController(0, 0); > //***** > > TIA, > Mark > > --here's the same code in context > > ////////////////////////////////////////////////////////////////////////// > > // 2 sliders to control FREQ and AMP of a sine wave > ( > w = GUIWindow.new("Sine Wave", Rect.newBy(40,80,200,100)); > > SliderView.new( // control freq > w, // window > Rect.newBy(20, 36, 160, 16), > nil, 440, 440, 880, 0, 'linear').mapToController(0, 0); > > SliderView.new( // control amp > w, // window > Rect.newBy(20, 56, 160, 16), > nil, 0.5, 0.1, 1, 0, 'linear').mapToController(0, 0); > > { > var freq, amp; > > freq = ControlIn.kr(w.at(0)); > amp = ControlIn.kr(w.at(1)); > > SinOsc.ar(freq, 0, amp); > > }.play; > w.close; > ) > > * * * * * * * * > Mark Polishook > Assistant Professor of Composition > Music Department > Central Washington University > Ellensburg, WA 98926 > > tel.: 509-963-1245 > fax: 509-963-1239 > e-mail: polishoo@cwu.edu > http://www.cwu.edu/~music/composition > > > * * * * * * * * > Mark Polishook > Assistant Professor of Composition > Music Department > Central Washington University > Ellensburg, WA 98926 > > tel.: 509-963-1245 > fax: 509-963-1239 > e-mail: polishoo@cwu.edu > http://www.cwu.edu/~music/composition > > > ------------------------------ End of sc-users-digest V1 #15 *****************************