From: owner-sc-users-digest@lists.io.com (sc-users-digest) To: sc-users-digest@lists.io.com Subject: sc-users-digest V1 #306 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, June 20 2001 Volume 01 : Number 306 ---------------------------------------------------------------------- Date: Mon, 18 Jun 2001 15:47:25 -0500 From: James McCartney <---@---.---> Subject: Re: London Supercollider Day - events I put this on the web site. http://www.audiosynth.com/publife.html - --- james mccartney james@audiosynth.com SuperCollider - a real time synthesis programming language for the PowerMac. ------------------------------ Date: Mon, 18 Jun 2001 15:57:38 -0500 From: James McCartney <---@---.---> Subject: Re: OSC: Max->SC Can you show me a hex dump of the data going into the max udp object? - --- james mccartney james@audiosynth.com SuperCollider - a real time synthesis programming language for the PowerMac. ------------------------------ Date: Tue, 19 Jun 2001 08:53:03 +1000 From: newton armstrong <---@---.---> Subject: Re: OSC: Max->SC James McCartney wrote: > Can you show me a hex dump of the data going into the max udp object? OSC_printcontents: buffer 1cc81528, size 32 23 (#) 62 (b) 75 (u) 6e (n) 64 (d) 6c (l) 65 (e) 0 () 0 () 0 () 0 () 0 () 0 () 0 () 0 () 1 () ffffffbb () ffffffbb () ffffffbb () ffffffbb () 2f (/) 73 (s) 63 (c) 2f (/) 70 (p) 69 (i) 6e (n) 67 (g) 0 () 0 () 0 () 0 () this is the Max patch: max v2; #N vpatcher 521 59 864 242; #P newex 210 34 45 196617 loadbang; #P message 210 54 40 196617 debug; #P button 54 58 15 0; #P newex 54 105 141 196617 otudp write 127.0.0.1 57123; #P newex 54 83 88 196617 OpenSoundControl; #P message 107 36 48 196617 /sc/ping; #P fasten 0 0 3 0 112 54 59 54; #P connect 3 0 1 0; #P fasten 0 0 1 0 112 79 59 79; #P fasten 4 0 1 0 215 76 59 76; #P connect 1 0 2 0; #P connect 5 0 4 0; #P pop; ------------------------------ Date: Mon, 18 Jun 2001 18:33:29 -0500 From: James McCartney <---@---.---> Subject: Re: OSC: Max->SC on 6/18/01 5:53 PM, newton armstrong at newton@hard.net.au wrote: > James McCartney wrote: > >> Can you show me a hex dump of the data going into the max udp object? > > OSC_printcontents: buffer 1cc81528, size 32 > 23 (#) 62 (b) 75 (u) 6e (n) > 64 (d) 6c (l) 65 (e) 0 () > 0 () 0 () 0 () 0 () > 0 () 0 () 0 () 1 () > ffffffbb () ffffffbb () ffffffbb () ffffffbb () > 2f (/) 73 (s) 63 (c) 2f (/) > 70 (p) 69 (i) 6e (n) 67 (g) > 0 () 0 () 0 () 0 () OK SC expects a tag string as described in "OSC message binary format" The tag string begins with a comma. So you need to append bytes 44 0 0 0 to the message. 44 is the ascii code of the comma char. - --- james mccartney james@audiosynth.com SuperCollider - a real time synthesis programming language for the PowerMac. ------------------------------ Date: Mon, 18 Jun 2001 16:55:28 -0700 From: tyamasa@haywire.csuhayward.edu Subject: Re: OSC: Max->SC hmm. maybe that's also what I needed when I had trouble: I didn't see the "tag string" thing in Max-to-Max OSC connection (it worked though. I was just using CNMAT's OTUDP and its example to learn OSC.) Where can I get "OSC message binary format" document? (or SC document has it all?) - ---------- >From: James McCartney <---@---.---> >To: >Subject: Re: OSC: Max->SC >Date: Mon, Jun 18, 2001, 4:33 PM > > on 6/18/01 5:53 PM, newton armstrong at newton@hard.net.au wrote: > >> James McCartney wrote: >> >>> Can you show me a hex dump of the data going into the max udp object? >> >> OSC_printcontents: buffer 1cc81528, size 32 >> 23 (#) 62 (b) 75 (u) 6e (n) >> 64 (d) 6c (l) 65 (e) 0 () >> 0 () 0 () 0 () 0 () >> 0 () 0 () 0 () 1 () >> ffffffbb () ffffffbb () ffffffbb () ffffffbb () >> 2f (/) 73 (s) 63 (c) 2f (/) >> 70 (p) 69 (i) 6e (n) 67 (g) >> 0 () 0 () 0 () 0 () > > OK SC expects a tag string as described in "OSC message binary format" > The tag string begins with a comma. So you need to append bytes 44 0 0 0 > to the message. 44 is the ascii code of the comma char. > > > --- james mccartney james@audiosynth.com > SuperCollider - a real time synthesis programming language for the PowerMac. > > > ------------------------------ Date: Mon, 18 Jun 2001 19:14:45 -0500 From: James McCartney <---@---.---> Subject: Re: OSC: Max->SC on 6/18/01 6:55 PM, tyamasa@haywire.csuhayward.edu at tyamasa@haywire.csuhayward.edu wrote: > hmm. maybe that's also what I needed when I had trouble: I didn't see the > "tag string" thing in Max-to-Max OSC connection (it worked though. I was > just using CNMAT's OTUDP and its example to learn OSC.) Where can I get "OSC > message binary format" document? (or SC document has it all?) All SuperCollider OSC functions require a tag string as the first argument to type check the arguments in the OSC message. The document is in the OSC help files included with SC. - --- james mccartney james@audiosynth.com SuperCollider - a real time synthesis programming language for the PowerMac. ------------------------------ Date: Tue, 19 Jun 2001 11:56:35 +1000 From: newton armstrong <---@---.---> Subject: Re: OSC: Max->SC James McCartney wrote: > OK SC expects a tag string as described in "OSC message binary format" > The tag string begins with a comma. So you need to append bytes 44 0 0 0 > to the message. 44 is the ascii code of the comma char. Thankyou, it works now. For anyone else trying to do this kind of thing, you need to be careful to match the data type conventions in respective environments. This is the correct format for sending from a Max message box to SC: /sc/postln \,is 1 aSymbol | | | address tags arguments ------------------------------ Date: Tue, 19 Jun 2001 00:42:32 -0400 (EDT) From: "Ronald J. Kuivila" <---@---.---> Subject: Re: OSC: Max->SC Here is some Pyrite code to create the appropriate type ID's to transmit from MAX to SC. (Ironic, isn't it?) RJK var typeTable; init { typeTable = [ ['float' 'int' 'symbol'] [102 105 115] ]; bitShifts = [24 16 8 0]; } OSCout { arg path ...theList; var tags; -- a list of typeTags in integer form --(i.e. ascii values) var tagInts; -- a packed version of tags; var tag, numTagInts, numTags; tagInts = []; tags = theList.collect({arg item; ^typeTable.assocAt(type(item)) }); tags.reverse; numTagInts = ((tags.size + 4)/4).asInt; for i = 0; i Subject: Re: OSC: Max->SC Ronald J. Kuivila wrote: > Here is some Pyrite code to create the appropriate type ID's > to transmit from MAX to SC. (Ironic, isn't it?) Thanks Ron. It seems to compile ok, but I get this message: € error: function 'bitShifts' called but not defined! Could you provide an example (a Max patch?) of how you send messages to the pyrite object? I'm not entirely clear on how the appropriate IDs are created. And does its output plug straight in to the OpenSoundControl object? ------------------------------ Date: Tue, 19 Jun 2001 04:00:05 -0400 From: christian adam hresko <---@---.---> Subject: Audio Anecdotes this a shameless plug, but i think a lot of people on this list would be interested in this book. i'm a contributing author for an upcoming book tentatively titled "Audio Anecdotes." it's being published by A.K. Peters and the editor is Ken Greenbaum (sworks). my article, titled "The Internal Structure of Audio Files" goes over in detail (oh the agony of detail...) the structure of AIFF, RIFF WAVE, NeXT/Sun, and RAW audio files. ever wonder what in the hell big endian and little endian means and what impact it has on file parsers and digital audio editing programs? why packed and unpacked headers have to be taken into account? is there really a difference between an AIFF and a RIFF WAVE file? does the word length of a machine have to be taken into account? what's a chunk, and how are chunks used? etc, etc... i believe at least one list member has read various drafts of the paper, and it's been heavily revised since then. a good deal of code is included, and the article is not only an audio file primer, but it also goes over the details one needs to write their own cross-platform audio file parser. machine architecture is discussed as well. i even wrote the article with upper case letters, and complete sentences! lots of other cool topics covered in the book are UGens, HRTFs, Synthesis Algorithms, Composition (music) techniques, Psychoacoustics, etc, etc... probably about 20 - 25 different topics all stemming from 15++ contributors working in various fields related to sound and/or music. it's going to be the equivalent of "Graphic Gems" for the digital audio community. so please check it out when it's released this summer. thanks. cheers, christian ------------------------------ Date: Tue, 19 Jun 2001 15:27:39 +0200 From: Julian Rohrhuber <---@---.---> Subject: Re: counting >is there a way, with a construct like this... > >Pseq([ > Pbind(stuff), > Pbind(stuff), > Pbind(stuff) >]).play > >..to increment a counter at the start of each new event in the Pseq? >i'd like to be able to send the counter value to a NumericalView in a gui >window. it would be better to increment it in the event, like a ~counter key. this would be done by another special kind of Pbind, I guess. if you want to have a count variable, you could easily add it to Pseq or just add it externally: var count; count = 0; ... Pseq([...], inf).collect({ count = count + 1 }) ------------------------------ Date: Tue, 19 Jun 2001 15:35:34 +0100 From: LUThER_SKIZZO <---@---.---> Subject: Pyrite sweet Pyrite... Hi Is anyone using JMC's Pyrite 8 successfully in Max 4.0.3? Sad enough, it doesn't work anymore in the new version of Max/MSP [at least for me :-(]. Basically, it just refuses to open the source code text files all the time and, naturally, cannot compile. BTW James, are you planning to update/upgrade Pyrite at some point or I should forget about it? Best lb - -- >>LUThER_SKIZZO_999.......................................///eventually//me// E hiss999@dircon.co.uk hiss999@dircon.co.uk hiss999@dircon.co.uk >>>it////////takes////a////fool///to////recognise//another/one/ >................................the.....end//////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////. ------------------------------ Date: Tue, 19 Jun 2001 10:59:26 -0400 (EDT) From: "Ronald J. Kuivila" <---@---.---> Subject: Re: OSC: Max->SC Sorry, missing init. The following expects the CNMAT OTUDP and OpenSoundControl objects together with Pyrite. Simply pass an OSC packet to the pyrite object and then send it on to the CNMAT OSC stuff. RJK RJK Here is the Pyrite code (parentheses delimit the beginning and end of the code - do not include them). (-- Take an OSC command and add the type tags needed by SuperCollider var typeTable; var bitShifts; init { typeTable = [ ['float' 'int' 'symbol'] [102 105 115] ]; bitShifts = [24 16 8 0]; ['OSCTimeTag' 0 0].out(1); } OSC { arg path ...theList; var tags; -- a list of typeTags in integer form (i.e. ascii values) var tagInts; -- a packed version of tags; var tag, numTagInts, numTags; tagInts = []; tags = theList.collect({arg item; ^typeTable.assocAt(type(item)) }); tags.reverse; numTagInts = ((tags.size + 3)/4).asInt; for i = 0; i Ronald J. Kuivila wrote: > > > Here is some Pyrite code to create the appropriate type ID's > > to transmit from MAX to SC. (Ironic, isn't it?) > > Thanks Ron. > > It seems to compile ok, but I get this message: > € error: function 'bitShifts' called but not defined! > > Could you provide an example (a Max patch?) of how you send messages to the > pyrite object? I'm not entirely clear on how the appropriate IDs are > created. And does its output plug straight in to the OpenSoundControl > object? > > ------------------------------ Date: Tue, 19 Jun 2001 21:10:14 +0200 From: Julian Rohrhuber <---@---.---> Subject: Re: counting > >var count; >count = 0; >... > >Pseq([...], inf).collect({ count = count + 1 }) this doesn't work. better: ( var c, a, s; c = 0; a = Pseq([1, 2, 3], inf).collect({ arg item; c = c + 1; item}); s = a.asStream; 10.do({ s.next; c.postln }); ) ------------------------------ Date: Tue, 19 Jun 2001 17:13:21 -0400 From: "crucial" <---@---.---> Subject: Re: connecting windows >i'm working on an idea here, and the first thing i need/want to know is >how i can pass data, messages, params, etc from one window (or gui) to >another. >i'm building something from scratch, so i'm not overly interested in >'custom' libraries just yet. btw. my 'custom' library is not a unified system. it is a collection of useful objects and approaches. there are some inter-locking systems. it makes no particular demands on doing everything within a system. where it does, is its weakness, and that's what is getting improved. it's purpose is to provide small reusable useful objects to put into anything you are doing to provide useful foundation classes to subclass that will let you make your own object just implement what is its idea-domain. > > >example: > >anOsc[GUI] >| >| >| >| >aFilter[GUI] >| >| >| >| >stereoOut[GUI] > > > >each GUI would be it's own 'patch' and NOT be enclosed in the same >Synth.play function. a Graphical User Interface in no way could ever be enclosed in a Synth's ugenFunction. i guess you mean 'object which also by the way has a nifty gui'. this object has a way to make sound, or affect sound, and it also has a gui. can it exist without its gui ? in my world this object is a Player, and it is capable of making one or more GUI of itself by sending it the .gui message. the specific type of Player you are proposing to build is called a Patch. >Synth.play would be evaluated after the code is >'linked' and consolidated into a single patch through my super-magic >programming. Patches can be 'consolidated' on the fly to composite patches. things other than patches can be part of the chain. Patch-es can have other patches as their arguments. They may be saved to disk that way. Patch-es may have their arguments dynamically overriden: filterPatch.ar([ differentOscPatch ]) Other linking systems are very possible and very welcome ! It sounds like you have maybe an interesting idea of how to link stuff. I am hoping my hard work will result in you using the Instrument / Patch system to do things like oscillators, filters etc. etc. (all stored in Orchestras or pages of Instruments as you like) You could then use Patch to handle the gui-ing, the automatic getting of usable sliders/ trig buttons etc. and get straight to the part about how you link them all together. And you can use your super-magic programming to build an object that takes a collection of Players and links them in all kinds of unimaginable ways. Note that my classes are intended NOT to take over your system. (and I'm making more changes to further that separation). you can use a Patch anywhere you would use a function. you can put anything that responds to .value into a Patch arg. you do not need to gui things. you do not need to save things to disk using the ultra-convienient composite-conscious load/save/no-clobber + backup system i have provided at no extra charge. You can use KrStream just to take a pattern, render it to a .kr signal and shove it into any ugen function or christian-code-bearing-slot. i just want to know how to 'snag' code from window (or >GUI) to window are you trying to use .generateCodeToClipboard to save patches ? highly anti-recommended. >and/or how to morph the existing params of a patch in one >window from another. if that makes any sense. If you don't want to use my code, at least examine it so that you come up with something better. If you think its cooler to start from 'scratch' then you don't understand programming. Do you think James would be cooler if instead of taking the standard SequenceableCollection he had come up with his own thing called BunchesOfThings ? or tackled the sortRange method without learning how other people had solved it ? I appreciate that you want to build stuff. Building stuff is fun. we all have model-train syndrome. I will not say that my objects are perfect concepts. they are a good start though, and I have written some breakable (and now broken) code in the past. i have learned from my mistakes,and from others. I'm really hoping I can lay out a useful shared framework so we can all move onto more exciting things like GA / NN, porting Swarm ideas to reusable SC objects. Chad Kirby made a cool EnvTable thing. I'm going to write an Adaptor object, and start using it to sequence or control any damn thing I want to. > > >cheers, > >christian > > > _____(( http://crucial-systems.com _________________))_______ ------------------------------ Date: Tue, 19 Jun 2001 16:29:10 -0500 From: James McCartney <---@---.---> Subject: Re: connecting windows on 6/19/01 4:13 PM, crucial at felix@crucial-systems.com wrote: > btw. my 'custom' library is not a unified system. it is a collection of > useful > objects and approaches. there are some inter-locking systems. Yes minimizing dependancies is best. If you only want one thing, it is a bummer if you find it requires lots of other stuff you don't care about to come along with it. - --- james mccartney james@audiosynth.com SuperCollider - a real time synthesis programming language for the PowerMac. ------------------------------ Date: Tue, 19 Jun 2001 17:45:31 -0400 From: "crucial" <---@---.---> Subject: Re: sc3d5 Instrument vs. my Instrument >on 6/16/01 4:25 PM, crucial at felix@crucial-systems.com wrote: > >> many of us have solved the "automatic gui window for a function" problem. >> some of us several times. I feel this system is the most flexible, simple and >> stable. >> > >Yes this sounds good. I will need some time to digest it. Yeah, me too. >If someone has better solutions than mine, I'd rather go with those. >So I would like to incorporate as many of yours and others' good ideas into >the system. Please let me know any areas you think aren't right and/or give me design advice. Sorry the code isn't completely cleaned up, I wanted to get it out there, knowing that some things would change. More thoughts over the weekend: Instr can easily become Instrument and keep backward compatibility. (sc2) I dropped guiNames, plugIds, protoControlViews, and inits from Instr. only specs are left. init is determined by the function's prototype or the spec's default. the plugID (linking via ControlSpace of a gui to a control object) should be handled by the specific control object. guiNames i wrote a looooottttttt of functions. never wanted to see anything but the argname up there. Patch is one way to play an Instrument. EventStream patterns are another. Patch is a subclass of AbstractPlayer. It doesn't have to be, but under my distribution it would be. It used to be a subclass of Instr, but I felt I was juggling/forcing it. Patch obtains default arg-satisfying-objects for its own purpose of playing that Instrument, IN THE WAY THAT PATCH PLAYS IT. generally a single event. Event Streams / Pattern library uses the Instrument in a different way. generally a series of events with args being streams Which also underscores why Instrument isn't the one to produce arg-satisfying-objects. TriggeredPatch could play the Instrument, retriggering it on (signal) trigger. arguments would be turned into streams and .next-ed on each event. DurationPatch would take a separate duration stream, and then retrigger the Instrument function, feeding in the arguments each asStream on each event. these 2 classes would have different default arg-satisfying-objects than Patch would. Spec____ i'm not sure about StaticSpec vs. ControlSpec and then also StaticEnumSpec vs. EnumSpec maybe canKr should just be a variable > >--- james mccartney james@audiosynth.com >SuperCollider - a real time synthesis programming language for the PowerMac. > > > > > _____(( http://crucial-systems.com _________________))_______ ------------------------------ Date: Tue, 19 Jun 2001 18:23:42 -0400 From: "crucial" <---@---.---> Subject: Re: connecting windows >on 6/19/01 4:13 PM, crucial at felix@crucial-systems.com wrote: > >> btw. my 'custom' library is not a unified system. it is a collection of >> useful >> objects and approaches. there are some inter-locking systems. > >Yes minimizing dependancies is best. >If you only want one thing, it is a bummer if you find it requires lots of >other stuff you don't care about to come along with it. and the process of making these things public has helped me a lot in recognizing those. i'm intrinsically learning the power of small classes with limited roles. and having broken stuff down, I can build new solid things much faster using the smaller classes. my biggest errors in earlier 'systems' (and they were much more systems) is putting too much power into a hierarchy. right now Player has some things that will go. I'm having a bit of trouble defining the class exactly, so I know there's still some breaking down to do. name, tempo, transport and tzmzones will go to a subclass as i knew they should. ideally it would be a simple concept like UGen. a Player is a higher-level object that .... 'plays when told to play' just a thought: look at how many places .play,.scope, fftscope etc. is implemented. it would be possible to separate all of those into classes in a simple Player heirarchy, so SoundFile would use SoundFilePlayer Function uses FunctionPlayer Pattern uses PatternPlayer / EventStreamPlayer which does more work than simply eg. sending to Synth.scope > >--- james mccartney james@audiosynth.com >SuperCollider - a real time synthesis programming language for the PowerMac. > > > > > _____(( http://crucial-systems.com _________________))_______ ------------------------------ Date: Wed, 20 Jun 2001 10:22:15 +1000 From: newton armstrong <---@---.---> Subject: Re: OSC: Max->SC Perhaps I'm missing something, but I think that this still needs a ',' character prepended to the tag string in order to send data to SC. Should be pretty simple, but it requires some bit shifting, and I wasn't sure exaclty where to hack your code. I can see how this little patch could be really useful - it's basically a dynamic typing extension to OSC. Ronald J. Kuivila wrote: > Here is the Pyrite code (parentheses delimit the beginning and end > of the code - do not include them). > > (-- Take an OSC command and add the type tags needed by SuperCollider > > var typeTable; > var bitShifts; > > init { > typeTable = [ ['float' 'int' 'symbol'] [102 105 115] ]; > bitShifts = [24 16 8 0]; > ['OSCTimeTag' 0 0].out(1); > } > > OSC { arg path ...theList; > var tags; -- a list of typeTags in integer form > (i.e. ascii values) > var tagInts; -- a packed version of tags; > var tag, numTagInts, numTags; > > tagInts = []; > tags = theList.collect({arg item; ^typeTable.assocAt(type(item)) }); > tags.reverse; > numTagInts = ((tags.size + 3)/4).asInt; > for i = 0; i numTags = tags.size min: 4; > tag = 0; > for j = 0; j < numTags; j = j + 1 do > tag = tag + (tags.pop << bitShifts.at(j)); > end.for > tagInts.add(tag); > end.for; > theList = path $ tagInts $ theList; > theList.out(1); > ['send'].out(1); > --['reset'].out(1); > } > > ) ------------------------------ Date: Tue, 19 Jun 2001 19:47:12 -0500 From: James McCartney <---@---.---> Subject: Re: OSC: Max->SC on 6/19/01 7:22 PM, newton armstrong at newton@hard.net.au wrote: > I can see how this little patch could be really useful - it's basically a > dynamic typing extension to OSC. In talking with Matt Wright it seemed that he was going to add these tags to MAX also, so that you could send arbitrary MAX lists between copies of MAX. In fact I added the comma character at his request. - --- james mccartney james@audiosynth.com SuperCollider - a real time synthesis programming language for the PowerMac. ------------------------------ Date: Tue, 19 Jun 2001 19:48:31 -0500 From: James McCartney <---@---.---> Subject: Re: Pyrite sweet Pyrite... on 6/19/01 9:35 AM, LUThER_SKIZZO at hiss999@dircon.co.uk wrote: > Hi > > Is anyone using JMC's Pyrite 8 successfully in Max 4.0.3? > Sad enough, it doesn't work anymore in the new version of Max/MSP [at least > for me :-(]. > Basically, it just refuses to open the source code text files all the time > and, naturally, cannot compile. > > BTW James, are you planning to update/upgrade Pyrite at some point or I > should forget about it? > > Best > > lb I found the source code. Unfortunately it is all Disk Doubler compressed. Using Stuffit Expander on these DD files is a pain because it appends a ".1" to each decompressed file name. - --- james mccartney james@audiosynth.com SuperCollider - a real time synthesis programming language for the PowerMac. ------------------------------ Date: Wed, 20 Jun 2001 04:06:47 +0100 From: LUThER_SKIZZO <---@---.---> Subject: Re: Pyrite sweet Pyrite... on 20/6/01 1:48 am GMT, James McCartney at asynth@io.com apparently typed: > I found the source code. Unfortunately it is all Disk Doubler compressed. > Using Stuffit Expander on these DD files is a pain because it appends a ".1" > to each decompressed file name. Hey Does that mean that you're going to try to find out what's the problem between Max 4 and Pyrite 8? If that's the case...:-) :-) :-) etc. Actually, the problem could be Max 4 itself since everything works well if I switch back to 3.6.2. Some stability problems but I don't care much. Maybe it'll work fine with Max 4.0.4 or 4.0.5........;-) Bear in mind that none of the Pyrite examples work for me at present. Perhaps is just my problem but I'm not sure. If I try to open, say, closures* [Max patch] this error occurs: € error: pyrite: can't open 'closures' and so on. If I double click on the *Pyrite closures* object a SAD empty text window comes out. Finally, all the text files containing Pyrite code open fine in Max, BBEdit, SimpleText, dear SC etc. Ta lb - -- >>LUThER_SKIZZO_999.......................................///eventually//me// E hiss999@dircon.co.uk hiss999@dircon.co.uk hiss999@dircon.co.uk >>>it////////takes////a////fool///to////recognise//another/one/ >................................the.....end//////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////. ------------------------------ Date: Tue, 19 Jun 2001 22:16:59 -0500 From: James McCartney <---@---.---> Subject: Re: Pyrite sweet Pyrite... on 6/19/01 10:06 PM, LUThER_SKIZZO at hiss999@dircon.co.uk wrote: > on 20/6/01 1:48 am GMT, James McCartney at asynth@io.com apparently typed: > >> I found the source code. Unfortunately it is all Disk Doubler compressed. >> Using Stuffit Expander on these DD files is a pain because it appends a ".1" >> to each decompressed file name. > > Hey > Does that mean that you're going to try to find out what's the problem > between Max 4 and Pyrite 8? If that's the case...:-) :-) :-) etc. no. but I might let someone else try it. > > Actually, the problem could be Max 4 itself since everything works well if I > switch back to 3.6.2. Some stability problems but I don't care much. > Maybe it'll work fine with Max 4.0.4 or 4.0.5........;-) > > Bear in mind that none of the Pyrite examples work for me at present. > Perhaps is just my problem but I'm not sure. If I try to open, say, > closures* [Max patch] this error occurs: > > € error: pyrite: can't open 'closures' and so on. > > If I double click on the *Pyrite closures* object a SAD empty text window > comes out. > > Finally, all the text files containing Pyrite code open fine in Max, BBEdit, > SimpleText, dear SC etc. > > Ta > > lb > > > - --- james mccartney james@audiosynth.com SuperCollider - a real time synthesis programming language for the PowerMac. ------------------------------ Date: Tue, 19 Jun 2001 23:32:59 -0400 From: "crucial" <---@---.---> Subject: Re: latency of keyDownAction I know this is an old message ( 1905 by my clock). but this is with sc3, right ? notice that sc2 does the same thing when its not playing. when it starts playing, the response is fast. this is an 'interrupt level' issue. >Hi James, > > There seems to be about a quarter second delay in a View's response to a >keyDownAction. Is there any way to speed this up? (I want to be able to >have people make simple performance instruments w/o any MIDI gear - just >mic, mouse, and keyboard.) > >RJK > > > _____(( http://crucial-systems.com _________________))_______ ------------------------------ Date: Tue, 19 Jun 2001 23:39:27 -0400 (EDT) From: "Ronald J. Kuivila" <---@---.---> Subject: Re: OSC: Max->SC I don't know what you mean - I have used the code successfully in installations in the spring of 2000. But I have not used it since. Have you actually tried it? (I am off in West Yellowstone right now and not in a position to check it out.) RJK On Wed, 20 Jun 2001, newton armstrong wrote: > Perhaps I'm missing something, but I think that this still needs a ',' > character prepended to the tag string in order to send data to SC. Should be > pretty simple, but it requires some bit shifting, and I wasn't sure exaclty > where to hack your code. > I can see how this little patch could be really useful - it's basically a > dynamic typing extension to OSC. > > > Ronald J. Kuivila wrote: > > > > Here is the Pyrite code (parentheses delimit the beginning and end > > of the code - do not include them). > > > > (-- Take an OSC command and add the type tags needed by SuperCollider > > > > var typeTable; > > var bitShifts; > > > > init { > > typeTable = [ ['float' 'int' 'symbol'] [102 105 115] ]; > > bitShifts = [24 16 8 0]; > > ['OSCTimeTag' 0 0].out(1); > > } > > > > OSC { arg path ...theList; > > var tags; -- a list of typeTags in integer form > > (i.e. ascii values) > > var tagInts; -- a packed version of tags; > > var tag, numTagInts, numTags; > > > > tagInts = []; > > tags = theList.collect({arg item; ^typeTable.assocAt(type(item)) }); > > tags.reverse; > > numTagInts = ((tags.size + 3)/4).asInt; > > for i = 0; i > numTags = tags.size min: 4; > > tag = 0; > > for j = 0; j < numTags; j = j + 1 do > > tag = tag + (tags.pop << bitShifts.at(j)); > > end.for > > tagInts.add(tag); > > end.for; > > theList = path $ tagInts $ theList; > > theList.out(1); > > ['send'].out(1); > > --['reset'].out(1); > > } > > > > ) > > ------------------------------ Date: Wed, 20 Jun 2001 14:48:11 +1000 From: newton armstrong <---@---.---> Subject: Re: OSC: Max->SC From: "Ronald J. Kuivila" <---@---.---> > I don't know what you mean - I have used the code successfully in > installations in the spring of 2000.  But I have not used it since.  Have > you actually tried it?  (I am off in West Yellowstone right now and not in > a position to check it out.) Yeah, I've tried it. It produces the now familiar message: € ERROR: expected ',' char at beginning of tag string. Perhaps the ',' requirement has been added to the OSC/SC protocol since your project last year? If you look at the hex output of the OpenSoundControl object in Max, it isn't there at the beginning of the tag, and I can't see a provision for it anywhere in your pyrite code. I'll have a play with it a bit later today, and post the code if I get it working. ------------------------------ Date: Wed, 20 Jun 2001 14:48:20 +1000 From: newton armstrong <---@---.---> Subject: Re: OSC: Max->SC This is an example of using OSC to pass data between Max and SC on the same machine. First experiments with this seem to suggest that it's much quicker and more efficient than using the IAC bus, and of course you don't have to work within the limitations of MIDI. I've been using this mainly to get data from external controllers that are not currently supported in SC. The SC patch is adapted from the OpenSoundControl examples file. The network settings (TCP/IP Control Panel) are: Connect via: Ethernet Configure: Manually IP Address: 205.45.67.2 Router address: 127.0.0.1 ( var pattern1, pattern2, pattern3, protoEvent, nodes; protoEvent = Event.protoEvent; pattern1 = Pbind( // bind names to value patterns \dur, 0.125, \pan, 0.5, // random walk melody with chance of an added third below \degree, Pbrown(0,7,1,8) + Prand(#[0, 0, [-2,0]], 8); ); pattern2 = Padd(\ctranspose, -24, Pbind( // bind names to value patterns \dur, 0.25, \pan, -0.5, \degree, Prand([ // bass & chord left hand patterns Pseq(#[0, 4, [7,9,11,14], 4]), Pseq(#[[0,7],[4,11],[2,9],[4,11]]) ]) ) ); pattern3 = Pbindf( Pseq([ Pfset( { ~mtranspose = #[0,1,2,3,4,5].choose; }, Ppar([ pattern1, pattern2 ]) // play patterns 1 & 2 in parallel ) ], inf) ); nodes = OSCNode.tree([ [\set, { arg node, name, value; // change a value in the protoEvent protoEvent.put(name, value); }], [\start, { arg node; pattern3.play(protoEvent, 2); }] ]); OSCPort.closeAll; OSCInPort(57123, nodes); ) max v2; #N vpatcher 591 46 980 437; #P comment 263 149 49 196617 transpose; #P number 224 148 35 9 0 0 0 3; #P comment 152 96 34 196617 tempo; #P comment 144 52 71 196617 stop synthesis; #P message 259 230 74 196617 symbol default; #P message 196 230 61 196617 symbol sine; #P newex 111 115 69 196617 maximum 0.1; #P message 230 255 118 196617 /set \\\,ss instrument \$1; #P message 70 29 50 196617 /start \\\,; #P flonum 111 95 35 9 0 0 1 3; #P message 78 50 62 196617 /sc/stop \\\,; #P message 224 168 115 196617 /set \\\,si ctranspose \$1; #P message 111 137 95 196617 /set \\\,sf tempo \$1; #P button 54 289 14 0; #P newex 68 333 141 196617 otudp write 127.0.0.1 57123; #P newex 68 312 88 196617 OpenSoundControl; #P comment 127 29 119 196617 start playing the Pattern; #P comment 209 213 56 196617 instrument; #P connect 10 0 4 0; #P connect 9 0 4 0; #P connect 7 0 4 0; #P connect 6 0 4 0; #P connect 5 0 4 0; #P connect 10 0 2 0; #P connect 9 0 2 0; #P connect 7 0 2 0; #P connect 6 0 2 0; #P connect 5 0 2 0; #P connect 4 0 2 0; #P connect 2 0 3 0; #P connect 8 0 11 0; #P connect 11 0 5 0; #P connect 16 0 6 0; #P connect 13 0 10 0; #P connect 12 0 10 0; #P pop; ------------------------------ Date: Wed, 20 Jun 2001 02:34:42 -0400 From: christian adam hresko <---@---.---> Subject: Re: connecting windows crucial wrote: > >i'm working on an idea here, and the first thing i need/want to know is > >how i can pass data, messages, params, etc from one window (or gui) to > >another. > > >i'm building something from scratch, so i'm not overly interested in > >'custom' libraries just yet. > > btw. my 'custom' library is not a unified system. it is a collection of useful > objects and approaches. there are some inter-locking systems. > it makes no particular demands on doing everything within a system. > where it does, is its weakness, and that's what is getting improved. i'm not sure if it's the way i compose my emails or what, but i'm obviously doing something wrong. i wasn't referring to ANY specific library or libraries written by anyone subscribed or not subscribed to this list. my statement was 'in general.' > > > it's purpose is to > provide small reusable useful objects to put into anything you are doing > to provide useful foundation classes to subclass that will let you make your own > object > just implement what is its idea-domain. yes, your library is impressive. > > > > > > > >example: > > > >anOsc[GUI] > >| > >| > >| > >| > >aFilter[GUI] > >| > >| > >| > >| > >stereoOut[GUI] > > > > > > > >each GUI would be it's own 'patch' and NOT be enclosed in the same > >Synth.play function. > > a Graphical User Interface in no way could ever be enclosed in a Synth's > ugenFunction. > i guess you mean 'object which also by the way has a nifty gui'. > this object has a way to make sound, or affect sound, and it also has a gui. > can it exist without its gui ? i'm not trying to enclose a GUI inside any function of any type. i'm trying to represent UGens in a graphical manner. these Graphcial UGens (GUGens...) can be connected in the same manner as UGens in SC code. the GUI 'object' (a GUGen) is a visual representation of the underlying code. therefore, the code can exist without the GUGen, but the GUGen will do nothing without the code. > > > in my world this object is a Player, and it is capable of making one or more > GUI of itself by sending it the .gui message. yes, i've played around with your library. > > > the specific type of Player you are proposing to build is called a Patch. i'm not sure if i want to use Player, and i'm not sure if i want to use .gui to create a 'Patch.' you're making too many assumptions about whether or not my original post was aimed towards the Crucial Library. again, it's a very impressive piece of work, and it seems like you took the time to implement a well designed system. > > > >Synth.play would be evaluated after the code is > >'linked' and consolidated into a single patch through my super-magic > >programming. > > Patches can be 'consolidated' on the fly to composite patches. things > other than patches can be part of the chain. i'll look into this. this is an interesting and useful aspect. > > > Patch-es can have other patches as their arguments. They may be saved > to disk that way. > > Patch-es may have their arguments dynamically overriden: > > filterPatch.ar([ differentOscPatch ]) > > Other linking systems are very possible and very welcome ! > It sounds like you have maybe an interesting idea of how to link stuff. > I am hoping my hard work will result in you using the Instrument / Patch system to do > things like > oscillators, filters etc. etc. (all stored in Orchestras or pages of Instruments as you > like) i'll look closer at the Instrument class and the Patch class. i think there's a good chance (as you stated...) that what you've done is similar to what i'm trying to do. i'm just not sure if there are enough similarities. give me some time to examine your library more closely. > > > You could then use Patch to handle the gui-ing, the automatic getting of usable > sliders/ trig buttons etc. and get straight to the part about how you link them all > together. > > And you can use your super-magic programming to build an object that takes a collection > of Players and links them in all kinds of unimaginable ways. yes, more things for me to investigate. > > > Note that my classes are intended NOT to take over your system. > (and I'm making more changes to further that separation). > > you can use a Patch anywhere you would use a function. > you can put anything that responds to .value into a Patch arg. > > you do not need to gui things. you do not need to save things to disk using the > ultra-convienient > composite-conscious load/save/no-clobber + backup system i have provided at no extra > charge. > > You can use KrStream just to take a pattern, render it to a .kr signal and shove it into > any ugen function > or christian-code-bearing-slot. this sounds good. > > > i just want to know how to 'snag' code from window (or > >GUI) to window > > are you trying to use .generateCodeToClipboard to save patches ? highly > anti-recommended. no. i'm not trying to save patches. i'm trying to access params that exist in one window or GUI from another window or GUI. the trick is, the GUIs are not part of the same patch until everything is linked, and executed. prior to the GUGen link process, the GUGens are independent of each other. however, they are 'aware' of each others existence during the pre-link stage. > > > >and/or how to morph the existing params of a patch in one > >window from another. if that makes any sense. > > If you don't want to use my code, at least examine it so that you come up with something > better. errr... i wasn't speaking specifically about your code. i'm sorry if this was in some way implied. > > If you think its cooler to start from 'scratch' then you don't understand programming. thanks. i don't understand programming. i suck at programming and there's really no point in me asking questions like these. i'm a moron and don't understand the complex world of programming and the benefits of code reuse through objects and extensible classes. > Do > you think > James would be cooler if instead of taking the standard SequenceableCollection he had come > up with his own thing called BunchesOfThings ? or tackled the sortRange method without > learning how other people had solved it ? no i don't think james would be cooler. i don't remember me saying anything about anyone being cooler. i'm a simple simple boy and i'm easily confused by all these technicalities. i've never worked with data structures, abstract data types, sorting techniques, etc, etc. the other day i was thinking of hashing my instruction set for my virtual machine using quadratic probing, but i realized i'm a moron and don't understand this bizarre world of programming.... > > > I appreciate that you want to build stuff. Building stuff is fun. we all have > model-train syndrome. > I will not say that my objects are perfect concepts. they are a good start though, and I > have > written some breakable (and now broken) code in the past. i have learned from my > mistakes,and > from others. > > I'm really hoping I can lay out a useful shared framework so we can all move onto more > exciting > things like GA / NN, porting Swarm ideas to reusable SC objects. hmmm... i've actually got a genetic algorithm environment (much improved since the previous release which didn't really work...) that i'm working on. when it's finished (for the time being) i'll send it to you if you'd like. okay. so this in no way answers my question about connecting windows. cheers, christian ------------------------------ End of sc-users-digest V1 #306 ******************************