| Author |
Message |
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
 Posted: Fri Jul 20, 2007 7:38 am Post subject:
|
  |
|
Very interesting. I'm going to have a good look at that paper.
_________________
Kassen |
|
|
Back to top
|
|
 |
Acoustic Interloper
Joined: Jul 07, 2007
Posts: 2067
Location: Berks County, PA
Audio files: 89
|
| Posted: Fri Jul 20, 2007 7:56 am Post subject:
|
|
|
| bachus wrote: | | Acoustic Interloper wrote: | | if the pattern matcher was a quantum computer, because then the state of the match would literally be all simultaneous possible accompaniments that you might hear in multiple sporking universes in which the piece is being performed, collapsing back to fewer than infinite universes on decoherence, and perhaps sporking persistent alternate universes for sets of really good performances. |
It's not clear to me that it would require a QC. Perhaps you'd only need find the appropriate integral form of the (Hilbert Space) superposition* vector? And If there was no such integral form of the vector it's not clear to me that QC could do the computation anyway. But then none of this is clear to me 
|
From any perception-constrained perspective there is probably no distinction. Depends on how literally you take the multiverse interpretations of quantum mechanics. Philosophical issue for now.
| bachus wrote: |
The superposition of state vectors is itself a state vector is it not? |
That pony has a very big trick 
_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
|
Back to top
|
|
|
elektro80
Site Admin
Joined: Mar 25, 2003
Posts: 21959
Location: Norway
Audio files: 14
|
| Posted: Fri Jul 20, 2007 8:07 am Post subject:
|
|
|
AFAIK, ponies are reasonably tricky these days.
    
_________________
A Charity Pantomime in aid of Paranoid Schizophrenics descended into chaos yesterday when someone shouted, "He's behind you!"
MySpace
SoundCloud
Flickr |
|
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004
Posts: 2922
Location: Up in that tree over there.
Audio files: 5
|
| Posted: Fri Jul 20, 2007 9:15 am Post subject:
|
|
|
| Acoustic Interloper wrote: | | Depends on how literally you take the multiverse interpretations of quantum mechanics. |
It's the only one of which I can make any sense. But I'm afraid your responses are still over my head. :icon for drooling idiot:
_________________
The question is not whether they can talk or reason, but whether they can suffer. -- Jeremy Bentham |
|
|
Back to top
|
|
|
bachus
Joined: Feb 29, 2004
Posts: 2922
Location: Up in that tree over there.
Audio files: 5
|
| Posted: Fri Jul 20, 2007 10:54 am Post subject:
|
|
|
Oh, we've been joking here...um well gee  I guess I went to far in that direction and need to reduce my Depakote now
_________________
The question is not whether they can talk or reason, but whether they can suffer. -- Jeremy Bentham |
|
|
Back to top
|
|
|
Acoustic Interloper
Joined: Jul 07, 2007
Posts: 2067
Location: Berks County, PA
Audio files: 89
|
| Posted: Fri Jul 20, 2007 12:35 pm Post subject:
|
|
|
| bachus wrote: | | Acoustic Interloper wrote: | | Depends on how literally you take the multiverse interpretations of quantum mechanics. |
It's the only one of which I can make any sense. But I'm afraid your responses are still over my head. :icon for drooling idiot: |
Over mine, too, but that's OK. Precisely where they belong. We can both take comfort in the fact that, in at least some universes of the multiverse, this all makes perfect sense, and that if there is no multiverse, then it's all nonsense.
There once was a Jack of all Trades    
As a Joker he did masquerade
He was played as a Pony 
then his mood it turned stoney 
losing tricks to a nymph of a maid 
_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
|
Back to top
|
|
|
Acoustic Interloper
Joined: Jul 07, 2007
Posts: 2067
Location: Berks County, PA
Audio files: 89
|
| Posted: Fri Jul 20, 2007 1:40 pm Post subject:
|
|
|
| Kassen wrote: |
I've come to believe that programing for electronic music has some unique challenges in that in electronic music there is no consensus on topics like what a "note" is or where a "instrument" ends, which creates problems because a formal language is going to need a exact definition. We've talked about those topics in this section a few times.... If you have clear ideas on the answers to those questions for your own (possibly temporary) setup then those should lead to reable code and at that point I think the danger of losing a lot of time and forgetting what you were after in the first place are nearly non-existant. |
This is right on the money. A personalized, extensible musical application oriented language or framework, along with tools for a) creating the personal language, b) creating structures in the language, and c) underlying foreign language APIs, for adding new primitives such as unit generators.
Does ChucK have a foreign language API for (c)? Given its OO extensibility, it seems a good candidate for (b), and maybe for (a).
Incidentally, in reading the MIDIME pipeline papers, if it were to treat timbre, some audio DSP processing would go in front of the current pipeline stage 1 (which reads MIDI after pitch-to-MIDI hardware conversion via MIDI guitar pickups), and plugin audio generators would go at the back end. The front end would want to so some spectral analysis to figure out what kind of sounds would work well for backend generator.
The current backend generators do have slots for Rhythm, Harmony, Melody and Timbre parameters (genes are strings of RHMT plugins), and actually there are long term Abstract variants of these genes for planning (A) and Concrete genes for generating aspects of MIDI events (pitch, velocity, program change, polyphony, etc.), but the timbre slots are limited to MIDI program changes mostly. So you really have 8 types of gene slots, AR, AH, AM, AT, CR, CH, CM, CT. Some can be filled with no-op generators. There's no machinery whatsoever for digital audio, but the conceptual architecture doesn't preclude doing it.
One problem with my code is that it is a pipeline. It only makes use of a dual-threaded Pentium if processing starts over-running the pipeline. Under normal circumstances, stage 1 completes the job of extracting stringed-instrument-state from a MIDI event before the next MIDI event arrives, and subsequent stages in the pipeline extract their more abstract data before the next MIDI event arrives. If a MIDI event *does* arrive before the pipeline has completed processing the prior event, the second Pentium thread does in fact kick in, but if this starts to happen consistently, the pipeline gets backed up. Pipelines are good for throughput but not for latency. A better strategy would be to find the bottlenecks in the pipeline (score matching is a likely candidate), clean up the algorithms (they probably need it), and then multi-thread an individual bottlenecked stage, not as a sub-pipeline, but as genuine parallel search. I am having some latency issues on complex pieces, and I am not sure if it's in my process or downstream, but I have a feeling that score matching is at least partly the culprit.
This is only MIDI. Digital audio might call for a bank of hardware DSPs.
_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
|
Back to top
|
|
|
Doni
Joined: Jul 11, 2007
Posts: 64
Location: Canada
|
| Posted: Fri Jul 20, 2007 5:55 pm Post subject:
|
|
|
I'm just going to say this:
I have no idea what you guys are talking about!!!! I don't know if I can take credit for this massive conversation.. but I'm just glad people are talking 
_________________
www.donimusic.com
www.myspace.com/donimusicspace |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Fri Jul 20, 2007 6:16 pm Post subject:
|
|
|
| Acoustic Interloper wrote: |
Does ChucK have a foreign language API for (c)? Given its OO extensibility, it seems a good candidate for (b), and maybe for (a).
|
Yes, no, and yes but not right now.
Yes; ChucK is open source, written in (I believe) C++ (if not c) and welcomes such things.
No, there is no real convenient way without diving in and recompiling the whole thing.
BUT, there should be hooks for that, I think those took a backseed for a while but there have been plans for diging those up again, having documentation for them and so on. This area seems quite vague right now, I think Ge is terribly bussy,
| Quote: |
Incidentally, in reading the MIDIME pipeline papers, if it were to treat timbre, some audio DSP processing would go in front of the current pipeline stage 1 (which reads MIDI after pitch-to-MIDI hardware conversion via MIDI guitar pickups), and plugin audio generators would go at the back end. The front end would want to so some spectral analysis to figure out what kind of sounds would work well for backend generator.
<snip>
|
I have yet to dive into your linked paper properly but with regard to what I wrote above; I think there are some dangers in defaulting to MIDI in that MIDI makes some heavy handed asumptions about things like "what a note is" and "where the instrument ends". For me MIDI tends to be something I "tunnel through". I think this is especially relevant with guitar-like instruments as those have polyphonic pitch-bend, note-off's that have a few dimentions and so on.
I'm not sure I'd treat the signals and patterns on a MIDI level in this case for pattern matching and so on. MIDI for better ot worse is a lowest common denometer but here it might be interesting to see wether a higher comon denometer could be found, after analysing the MIDI as a first stage and building a abstraction from that. But; that's just my look at this right now, I'd have to read a bit more to say anything more relevant and practically usefull.
_________________
Kassen |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Fri Jul 20, 2007 6:21 pm Post subject:
|
|
|
| Doni wrote: | I'm just going to say this:
I have no idea what you guys are talking about!!!! I don't know if I can take credit for this massive conversation.. but I'm just glad people are talking |
I think we're all going off in a few directions at once; you listen to music, you play music and you think about music so you should just chime in, there are lots of problems and any perspective on them is already quite interesting; I think it's safe to say we're all out of our depth and so is the rest of the world so there is no real use in feeling intimidated as that doesn't matter.
:¬)
_________________
Kassen |
|
|
Back to top
|
|
|
mosc
Site Admin
Joined: Jan 31, 2003
Posts: 18198
Location: Durham, NC
Audio files: 213
G2 patch files: 60
|
| Posted: Fri Jul 20, 2007 6:25 pm Post subject:
|
|
|
| Kassen wrote: | | ... we're all out of our depth and so is the rest of the world so there is no real use in feeling intimidated as that doesn't matter. |
Yep... well said...
_________________
--Howard
my music and other stuff |
|
|
Back to top
|
|
|
Acoustic Interloper
Joined: Jul 07, 2007
Posts: 2067
Location: Berks County, PA
Audio files: 89
|
| Posted: Fri Jul 20, 2007 8:32 pm Post subject:
|
|
|
| mosc wrote: | | Kassen wrote: | | ... we're all out of our depth and so is the rest of the world so there is no real use in feeling intimidated as that doesn't matter. |
Yep... well said... |
I'll second that. We're all just kids turning over rocks to find out what's underneath them. Big universe. Lotta rocks.
Have a good weekend.
_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
|
Back to top
|
|
|
Acoustic Interloper
Joined: Jul 07, 2007
Posts: 2067
Location: Berks County, PA
Audio files: 89
|
| Posted: Fri Jul 20, 2007 9:05 pm Post subject:
|
|
|
| Kassen wrote: |
I think there are some dangers in defaulting to MIDI in that MIDI makes some heavy handed asumptions about things like "what a note is" and "where the instrument ends". For me MIDI tends to be something I "tunnel through". I think this is especially relevant with guitar-like instruments as those have polyphonic pitch-bend, note-off's that have a few dimentions and so on.
|
Yeah, I am not entirely happy about MIDI, although mostly at the back output-synthesis end of my pipeline rather than the input-pattern matching end of things. I miss hearing the unique, well-designed acoustics of my open back five string banjos (recently acquired my 4th one and am thinking hard about a 12 string acoustic guitar that my son and I both played at a store recently). That's why I have started playing with Live and am thinking about ChucK. My primary goal on this first go-around of processing audio, is just to bring out, highlight and extend the audio dynamics that already exist in each of these instruments. Basically acoustic instrument sound enhancement. Beyond that, though, finger picking is a very cyclic, rhythmically mathematical activity, amenable to some of structural tricks of minimalism, which is why I started digging into that. MIDI is going onto the back burner somewhat.
Although I will say, at least for the Godin MIDI guitar I bought 2 years ago, the MIDI events are exactly what I need for finger picking analysis. It gives noteon events only for string plucks with my right hand. Chokes, slides, pulls and hammers, even hard hammers that I would think would cause noteons, are happily all treated as pitch bends. Only right hand picking causes noteon, and it does so consistently. That is precisely what I need to analyze finger patterns. So, no loss for MIDI here. The loss is in losing spectral information on pitch to MIDI conversion, and also less than total satisfaction with the synthesized output from the software synths I have tried so far. But, I haven't really tried that many.
What one would really like would be two signals, incoming digital audio from the strings and MIDI from the same strings, along with sync information showing where the two line up in time. (My guitar gives everything except the sync.) Then pattern matching software could use the simplifications of MIDI where its data are sufficient, but always with the opportunity to tap into the audio spectrum when desired. But, if I turn over that rock, I may get trapped under there. In the meantime, I am having a lot of fun shooting points of banjo sounds through software FX chains.
| Quote: |
I'm not sure I'd treat the signals and patterns on a MIDI level in this case for pattern matching and so on. MIDI for better ot worse is a lowest common denometer but here it might be interesting to see wether a higher comon denometer could be found, after analysing the MIDI as a first stage and building a abstraction from that. But; that's just my look at this right now, I'd have to read a bit more to say anything more relevant and practically usefull. |
Yes, my pipeline does build those higher level abstractions. The abstractions are:
1. incoming midi
2. a map of instrument string/fret state
3. bind parameters for current meter, tempo, scale(s), chord(s), drone(s), melody notes, based on analysis of of stage 2.
4. bind current performance to current position in a score, based on comparing output of stage 3 to stored/merged traces of previous performances' stage 3 output
5. generate and synchronize MIDI output using plugins that monitor output of above 4 stages and also monitor other stage 5 plugins. Monitoring stage 5 peers supports high level, abstract looping.
Hope you enjoy the papers. Let me know if you have any questions.
Take care.
_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
|
Back to top
|
|
|
Doni
Joined: Jul 11, 2007
Posts: 64
Location: Canada
|
| Posted: Sat Jul 21, 2007 9:54 am Post subject:
|
|
|
That's some high level stuff....
My whole approach to music production hasn't really been that technical, I just play with parameters (almost unconsciously at this point) until I get some the results I want. Sometimes what I hear in my head doesn't come out of my monitors, sometimes I have happy accidents that take songs in different directions...
I have done some research on technical stuff, but I've never gone this deep into it... I do imagine I will reach a point where getting deeper into the technical side of things may be important, but I think many producers get too concerned with technicalities. For example, I've got a friend, he's got a sound engineering degree, but he's made no progress with it because he cant afford the equipment "he needs" to acheive technical bliss. I say booo!!!
See, that friend of mine is stuck in believing that there is only one way to make productions, the way he was taught in school, which is bullox
I'm completely self taught, I think ive got some pretty cool recordings and I plan to make a career out of this, but my studio is pretty much in my bedroom at this point
does that mean I wont ever build my own studio? Not likely. I'm saving for it right now (uhhh hopefully not forever..)
anyways, ive kind of strayed from my point a little here, I just think being overly technical can hurt a new producers progress... I dont think y'all are in that situation, but I am sure there are newbies following this thread, so I thoguht I would chime in for them
_________________
www.donimusic.com
www.myspace.com/donimusicspace |
|
|
Back to top
|
|
|
iPassenger
Joined: Jan 27, 2007
Posts: 1067
Location: Sheffield, UK
Audio files: 5
G2 patch files: 78
|
| Posted: Tue Jul 31, 2007 2:03 am Post subject:
|
|
|
I think this One trick pony thing is poor. One of my music making collegues insists on using the same drum samples, synth sounds, arrangement techniques and mixing tricks in every track he writes. Personally I would find that approach extremely dull. And altho I readily admit I have a few tricks that are often brought in to finish tracks off, I like to think that the majority of my finished works are based around a new one off compositional/arrangement/soundset (every time)/or all three technique (s). Otherwise what are you really providing to the music market place?
I'm sure there is continuinty in my work from one track to the next but that is due to my ears and musical history but the way i realise that texture/feel/emotion/continuity will be different every time. In fact one of the reasons i do not finish as many tracks as I could is because I often sack stuff off for being hackneyed or to a formula, regardless of wether it actually sounds good or not, I would imagine the same is true for many of us on this forum.
_________________
iP (Ross)
- http://ipassenger.bandcamp.com
- http://soundcloud.com/ipassenger |
|
|
Back to top
|
|
|
Doni
Joined: Jul 11, 2007
Posts: 64
Location: Canada
|
| Posted: Tue Jul 31, 2007 5:29 pm Post subject:
|
|
|
Definitely.... like for example... there are some unnamed drum and bass producers that use the same dam break for every track. It's frustrating to see established musicians do the job like that. To these producers.. it is a job.. which is something very mysterious to me
_________________
www.donimusic.com
www.myspace.com/donimusicspace |
|
|
Back to top
|
|
|
dewdrop_world
Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4
|
| Posted: Tue Jul 31, 2007 7:10 pm Post subject:
|
|
|
| Doni wrote: | | Definitely.... like for example... there are some unnamed drum and bass producers that use the same dam break for every track. It's frustrating to see established musicians do the job like that. To these producers.. it is a job.. which is something very mysterious to me |
Amen, brother! (groan)
Of course, I've no room to talk. I used Apache in a track once.
  
James
_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Wed Aug 01, 2007 10:50 am Post subject:
|
|
|
Neither are as bad as the "think" break. I can't stand that one.
Oh, and randomisers in auto-cutters. Somebody should at least apply Markov chains to those (hmmm, with bbcut... that might actually work quite well).
_________________
Kassen |
|
|
Back to top
|
|
|
Acoustic Interloper
Joined: Jul 07, 2007
Posts: 2067
Location: Berks County, PA
Audio files: 89
|
| Posted: Thu Aug 02, 2007 6:52 am Post subject:
|
|
|
| Kassen wrote: | | Neither are as bad as the "think" break. I can't stand that one. |
Maybe I can make some good money writing the "Snooze Button Plugin."  Bring your dreams to life whilst performing 
| Quote: | | Oh, and randomisers in auto-cutters. Somebody should at least apply Markov chains to those (hmmm, with bbcut... that might actually work quite well). |
My current favorite randomizer is to set up some mechanism whose trigger depends on precise timing on my part, such that a fraction of a second early on my part sends the piece in one direction, and a fraction late sends it in another. The butterfly effect. No outside randomization, just ear&eye-to-hand. And, why stop at just one 
_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
|
Back to top
|
|
|
Acoustic Interloper
Joined: Jul 07, 2007
Posts: 2067
Location: Berks County, PA
Audio files: 89
|
| Posted: Sat Aug 04, 2007 2:49 pm Post subject:
|
|
|
| Kassen wrote: | | I like Live, but Live only does so much and what it does it tends to do in speciffic ways. I'd like to repeat my recomendation to have a look at LiSa, that's a triccky little ugen :¬) |
Yeah, I am starting to see the blessings and curses of these performance environments (at least Live), and the blessings and curses of being a computer scientist doing music. Live's been great for doing the modulo-8th-note-delays-against-banjo-finger-picking-patterns-a-la-minimalism, but interestingly, a voice sample of my daughter reading her creative writing composition, "Ordinary Machinery," is what's making me think twice about the COTS (Commercial Off the Shelf) software approach here.
Basically, I started out cutting up my daughter's voice-text samples into segments that I could rearrange using the cut-up technique begun by William Burroughs and others in the mid 1900's. Bringing these 'clips' into Live, it wasn't long until I found how easy it is to phase a couple of copies of a given clip aginst each other, so I can get something loosely derivative of Reich's early work with tape. I found I could also get something *differnt* from this by applying Burroughs' cut-up (basically meaning cut & paste in a different order) to individual syllables. I could put new words into her mouth, like doctoring a photo. Now this is really interesting, because I can morph the *meaning* of her voice text samples over time at one conceptual level of abstraction, while I morph the sound via phasing at another.
Trouble is, Live isn't an open architecture, and trying to prep this 2-level approach rapidly blows up the number of clips. What I'd really like is a fairly simple grammar stored as text on the computer, with links to words and syllables in her voice sample, so I can manipulate the semantic part of this by rearranging text words or syllables, just like I am doing here. In a sense her voice sample would act as a sampled speech synthesizer.
Of course, Live is not a readily open architecture for doing this sort of thing. There is a Python API apparently, but that's an awful lot of overhead and may not get the job done.
So, I am beginning to get the lure of ChucK after only a few weeks. If you have an idea like creating a textGrammar-to-voiceSample mapping so you can perform the latter by manipulating the former, the target pretty much *has* to be a programming language. In a general sense we are talking a CASE tool (Computer Aided Software Engineering) for ChucK or a similar musical target language.
Funny, this is how Mosc and I met in 1990, working on a project for software tools to generate circuitry from code. Now maybe software tools to generate ChucK code from abstractions like text grammars, or Markov Chains  I'm glad there's some months before EL2008. I'd hate to be having these little epiphanies at the last minute.
_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
|
Back to top
|
|
|
dewdrop_world
Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4
|
| Posted: Sun Aug 05, 2007 6:58 am Post subject:
|
|
|
| Acoustic Interloper wrote: | | So, I am beginning to get the lure of ChucK after only a few weeks. If you have an idea like creating a textGrammar-to-voiceSample mapping so you can perform the latter by manipulating the former, the target pretty much *has* to be a programming language. In a general sense we are talking a CASE tool (Computer Aided Software Engineering) for ChucK or a similar musical target language. |
Or SuperCollider for that matter.
Out of curiosity, what is the lure of ChucK for you that isn't there in SuperCollider? Just would be interesting to compare... they are quite different animals with different strengths and weaknesses.
James
_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net |
|
|
Back to top
|
|
|
Acoustic Interloper
Joined: Jul 07, 2007
Posts: 2067
Location: Berks County, PA
Audio files: 89
|
| Posted: Sun Aug 05, 2007 4:01 pm Post subject:
|
|
|
| dewdrop_world wrote: | Out of curiosity, what is the lure of ChucK for you that isn't there in SuperCollider? Just would be interesting to compare... they are quite different animals with different strengths and weaknesses.
James |
I plead ignorance. Please enlighten me. What I know about ChucK, taken mostly from the 3.5 hour intro & tutorial at EM2007, is:
1. It can do MIDI or digital audio, so as long as the library of ugens is good & getting better, I can probably skip learning Max/MSP. I have programmed in dataflow pictorial environments like Max before, although not for music. Used a 3D graphical dataflow language for a while in 1983, actually, and have used them in circuit simulations since then. But, once I know the library & syntax, I can knock code out faster using an algebraic notation.
2. Princeton is a short drive, and I get down there fairly often. So, if I do anything impressive with ChucK (no predictions here), there is always the possibility of collaboration.
3. It's got object oriented inheritance, which I use a lot.
4. It's got OSC communication, which looks promising & is something I want to learn.
Bigeest downside so far is that I don't think it has a supported API out to C or c++ or Java, so if I wanted to add a ugen, I don't think I can. I guess they'll be adding this eventually.
My first intended apps will be fairly straightforward processing of audio signals from the banjo. Later on I may look at tagging sample voice stream files with file offset markers that link back to text representation of what's in them, so I can manipulate voice signals using a grammar-based approach. Also considering graphical Markov chains or similar state machines to do live coding via interaction with a stack of state machines that operate at different levels of abstraction -- sections, musical phrases, chords, drones, etc., sort of the inverse of the midime pipeline; midime parses musical structures, whereas this would be aimed at generating from interacting with structures, sort of live coding on steroids. The OSC hook out to Python may help here.
Is there a development team for Supercollider? Please feel free to point me at info or convince me. Thanks
_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
|
Back to top
|
|
|
dewdrop_world
Joined: Aug 28, 2006
Posts: 858
Location: Guangzhou, China
Audio files: 4
|
| Posted: Sun Aug 05, 2007 7:19 pm Post subject:
|
|
|
Heh heh... soapbox time...
SuperCollider scores on all four of your points, actually:
1. SuperCollider has MIDI input and output, and an audio engine that is surprisingly efficient. The architecture is very different from ChucK, though. SuperCollider uses a client/server architecture -- the language is the client, which sends OSC messages to the server (which is responsible for audio rendering).
2. There are probably some sc users at Princeton -- Paul Lansky uses it a lot. (Plus with OSC, there is no reason you couldn't collaborate with ChucK users.)
3. The SuperCollider language is basically SmallTalk with a syntax that is superficially more like C, and special classes to build signal flow graphs using code (including arithmetic expressions). Lots of powerful Collection and Pattern classes too (Patterns are like generators in SmallTalk). Realtime garbage collection. Scheduling and OSC message timestamps are integrated for precise timing of sound events.
4. OSC is integral to SuperCollider. It's the only interface to the server -- no OSC, no audio. The client can send OSC using the NetAddr class, and receive using OSCresponder and related classes. (There are also node object classes that can hide the server messaging details, good for readability.)
(5. UGens are all plugins with an open and documented API, and there are 3rd party ugens out there for download.)
SC is maintained here - http://supercollider.sourceforge.net/mod/resource/view.php?id=31 - and is in active development. The current feature set is pretty stable. Mac OSX and Linux builds are full-featured, with the Windows port lagging behind.
I've been using SC for just shy of five years now and I never looked back -- it fits me like a glove, just the right level of abstraction for me.
ChucK is an awesome, radical concept and I have tons of respect for Ge -- at the same time, I recognize sc's advantages that keep me using it (apart from the massive body of code have produced over the last few years). It's mature and stable, and scary efficient in performance. Plus, for the kind of complex modeling you want to do, I think you would find sc's library to be pretty rich.
As to which one suits you better, only you can decide... these are just my opinions.
_________________
ddw online: http://www.dewdrop-world.net
sc3 online: http://supercollider.sourceforge.net |
|
|
Back to top
|
|
|
Acoustic Interloper
Joined: Jul 07, 2007
Posts: 2067
Location: Berks County, PA
Audio files: 89
|
| Posted: Mon Aug 06, 2007 7:14 am Post subject:
|
|
|
| dewdrop_world wrote: | | The current feature set is pretty stable. Mac OSX and Linux builds are full-featured, with the Windows port lagging behind. |
Yep, took a look last night, looks pretty interesting. I have a few simple mechanisms to try, so I'll test drive 'em in both SC and ChucK and see how it goes.
I'm running Windows XP, and at least some aspects of the ChucK port are lagging as well. How far back is Windows lagging? For his birthday in May I bought my son our first Apple machine in 27 years, a Macbook Pro with mbox 2 & protools le, and he's pretty happy with it. I am do for a more portable machine; this + the arrival of MS Vista may just push me over to Mac. Don't like MS.
I'll let you know how the test drive goes. Thanks for the summary.
_________________
When the stream is deep
my wild little dog frolics,
when shallow, she drinks. |
|
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3
|
| Posted: Mon Aug 06, 2007 7:59 am Post subject:
|
|
|
| Acoustic Interloper wrote: |
I'm running Windows XP, and at least some aspects of the ChucK port are lagging as well. How far back is Windows lagging? |
The only thing I can think of is graphical user interface elements in the Mini Audicle. Untill resently the Windows version had issues with multi-channel and low-latency audio but the ASIO version fixed that.
New versions of ChucK tend to be released for all three OS's at the same time, if those aren't identical in behaviour that likely means there is a issue or bug.
James is of course 100% right with all of his observations, I'd like to add that IMHO the main things ChucK has going for it are it's very accessible (to new programers) syntax that I find very expressive (but that's a matter of taste) and the intergrated editors.
_________________
Kassen |
|
|
Back to top
|
|
|
|
Forum index » Discussion » Composition
FAQ
Calendar
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Chat Room
