Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Tue Jul 15, 2008 2:09 am Post subject:
Inventor wrote:
If you want a sequencer, make a Boolean Sequencer! Also, why doesn't PyChucK have filters?
With all the logic gate waveshaper and stuff I think you could make a boolean sequencer even without shreds but I'm not too keen on algorithmic composition. I like music to go places with a sense of purpose and drawing from Sir Penrose's writings I've concluded that machine's are void of intention. I applaud those who discover good algorithmic drones but I'd like to discover music from mind itself.
Also I'm a control freak perfectionist with a classical background so I'd really like to see functional note sheets written in code. :P
Filters are next on the list of UGens to be implemented but I'm finding a myriad of bugs in the rest of the code so UGens are on hold for a while. _________________ To boldly go where no man has bothered to go before.
If you want a sequencer, make a Boolean Sequencer!
Wouldn't it make more sense to treat Boolean Sequencing as a set of functions that could be applied to any "normal" sequencer object? _________________ Kassen
Joined: Oct 13, 2007 Posts: 6221 Location: near Austin, Tx, USA
Audio files: 270
Posted: Tue Jul 15, 2008 4:29 pm Post subject:
Kassen wrote:
Inventor wrote:
If you want a sequencer, make a Boolean Sequencer!
Wouldn't it make more sense to treat Boolean Sequencing as a set of functions that could be applied to any "normal" sequencer object?
Why yes, what a concept! A language could have a way to define some logic equation, then form the noteon and frequency terms from those equations. The simplified, boiled down form of Boolean Sequencing that I put into Guitar Lab is just the classic sum of products logic. So we could make an SOP ugen defined like this: Counter c => SOP sop => SinOsc s, then later on we might have initialization like this: 0 => c; 0101011110011 => sop; and such.
Also Frostburn, though you may be a self-described control freak, perhaps that's what drives you to create such perfectly structured code. I am learning, partly from Kassen actually, that my greatest weakness is in fact responsible for helping me to be so creative. So let's all celebrate our forked-upedness, it's a good thing, haha! Or should I say "Muhuhahaha!" _________________ "Let's make noise for peace." - Kijjaz
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Wed Jul 16, 2008 6:46 am Post subject:
I'm having trouble linking JACK and Python together but according to a testimonial it may not even be worth the effort. It says that the Python Interpreter is simply too slow for real time use and all you can do is prepare the audio data beforehand, connect to JACK, play it back and disconnect.
It might be possible to embed JACK directly at the C module level so that it doesn't have to touch Python directly but I don't feel I'm up for such a challenge, yet.
OSS on the other hand has too much latency for any serious real time work but it'll have to do for now. At least with OSS you don't have to wait until the whole render is complete to hear the sound.
Too bad it's a no go for adc and MIDI for now.
Oh well. I wasn't expecting PyChucK to run in real time anyway... luckily we just got a brand new ChucK for that. :) _________________ To boldly go where no man has bothered to go before.
I'm having trouble linking JACK and Python together but according to a testimonial it may not even be worth the effort. It says that the Python Interpreter is simply too slow for real time use and all you can do is prepare the audio data beforehand, connect to JACK, play it back and disconnect.
This is still true for most (any?) interpreted, virtualized, or just-in-time-compiled language. That's why pretty much all audio software is still written in C or C++.
That doesn't mean Python can act as a good control language though, as long as it's not directly in the rendering loop, it can be used to set up connections between modules written in C, and modulate parameters at slower speeds (between audio buffers). That's basically how Chuck works actually, except that the Chuck language can intercept between every sample if you ask it to, though you'll notice that when you use a 1-sample while{} loop in Chuck the CPU usage goes through the roof, so it's not really recommended.
If you're looking for an easy way to add JACK/ALSA support, I suggest you try rtaudio, which is also used by Chuck. It provides a single C++ class you can use to represent the audio device, and you just have to provide a callback function which renders the audio stream.
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Wed Jul 16, 2008 8:51 am Post subject:
Hmm... Supporting ALSA would be nice, I'll look in to rtaudio in the future.
The callback function still has to call Python functions via the VirtualMachine so that shreds (generators in Python) stay sample accurate. Python has quite a lot of flexibility with garbage collection and all so I think it's possible to pull off. It just requires more work than I thought it would. _________________ To boldly go where no man has bothered to go before.
Joined: Jul 07, 2007 Posts: 2081 Location: Berks County, PA
Audio files: 90
Posted: Thu Jul 17, 2008 6:58 am Post subject:
Frostburn wrote:
I'm not too keen on algorithmic composition. I like music to go places with a sense of purpose and drawing from Sir Penrose's writings I've concluded that machine's are void of intention. I applaud those who discover good algorithmic drones but I'd like to discover music from mind itself.
Also I'm a control freak perfectionist with a classical background so I'd really like to see functional note sheets written in code.
For me the most satisfying algorithmic compositions are still compositions in the sense of the composer seeding his/her devious sense of aesthetics and humor into the code and data , but leaving some interesting parameters unbound until performance time, and some of them non-deterministic from the performer's point of view.
I've been trying to do this with the Python => (ChucK || SC || MaxMSP) chess to music program that I've posted elsewhere. There have been incremental enhancements to both the Python-algorithmic component and the audio language patches that are human composition; the algorithmic composition component of this is a subset of my composition, not the other way around. In fact, from the composer's perspective, the program is completely deterministic. There is no arbitrary aleatory chance in its decisions, no call to a random() function. However, the actual performance of the piece is guided in part by three performance-time activities:
1. The play of the game.
2. Adjustments of game-to-music mapping parameters in a GUI. The adjustments are pretty intuitive in the context of the game.
3. The timing of moves, along with time-related mapping parameters.
So, two identical games could come out quite differently, depending on 2 and 3. 3 helps to add some variety and even non-predictability.
It's interesting that you mention Penrose, because my perspective on composition has been shaped largely by quantum mechanics, especially the concept of a superposition. The score can be seen as a superposition of possible performances, with some performance variables left unbound, to be bound at performance time, by performers and listeners and performance space and instrument state. So, everyone involved gets to contribute in binding notes within a superpositional, probabilistic structure, but the binding is not arbitrary or random. It involves the constraints imposed by the actual superpositional composition (i.e., the human composer's intent) -- which may be very binding in some regards and very loose in others -- and the people and space involved in the performance. In binding performance-time parameters, they collapse the probability space into a unity probability of something actually coming out as music, or at least as sound
Granted, a digital superposition in a digital computer is not as theoretically powerful as a quantum superposition, but it is still possible to construct a digital superposition that is true to the composer's intent without making it entirely predictable, with the unpredictability coming from its generative power, not from arbitrary randomness. Just like the fact that there are certain things that are predictable about snowflakes and others that are not.
My next set of planned experiments have to do with capturing and processing room feedback while playing mic'd string instruments. This started out trying to minimize acoustic feedback while playing a mic'd acoustic banjo which I am looping through delays that are small multiples of my finger picking speed (320 millisecond canons). Works fine in headphones, but with the mic I am using (wonderful sensitivity and frequency response but fairly crappy directionality) I have problems in some patches when I switch to loudspeakers. In the process of trying to minimize the room feedback I started working with, instead, capturing and processing it, along with the banjo, in the loops. Playing the room. I'm sometimes surprised at the way this "binding the superposition at play time" can manifest itself.
Anyway, I don't think algorithmic composition is necessarily mechanical or random or arbitrary, and I agree that control by the composer is critical in actually creating an identifiable, coherent composition, but I think that control can come in the form of constructing generators with some interesting unbound parameters. And, I think Python and these audio generator languages are great for that. Great fun, too. _________________ When the stream is deep
my wild little dog frolics,
when shallow, she drinks.
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Fri Jul 18, 2008 6:02 am Post subject:
Interesting post you made there Interloper.
I'll have to read that pdf you posted and get back to this topic of quantum composition.
But on the topic of algorithmic composition it's just that sometimes people claim that they made a musical piece that turns out to be completely algorithmic. I'd say that they crafted the algorithm but simply discovered the mapping from data to notes. It's the rules manipulating the underlying data that create the piece and thus there's no sentient being who made it.
Algorithms are the raw material and it's up to the sentient composer to make the decisions where and how they act. The merit of the composer is that of organizing not of creating melodies.
But hey purely algorithmic pieces are not bad, I'll probably make(I mean discover) a few for the examples to go with PyChucK. (And I really need to start documenting the stuff too. I'm having hard time figuring out my own code already. ) _________________ To boldly go where no man has bothered to go before.
Joined: Jul 07, 2007 Posts: 2081 Location: Berks County, PA
Audio files: 90
Posted: Fri Jul 18, 2008 7:41 am Post subject:
Frostburn wrote:
Interesting post you made there Interloper.
I'll have to read that pdf you posted and get back to this topic of quantum composition.
Thanks. There are some related slides from an electro-music 2006 talk/demo here. The paper is just a draft of that quantum superposition concept glued onto the front of another paper on the MIDI guitar pattern recognition algorithms fleshed out more cleanly here. Some day after I do some more related work, I'd like to flesh out this quantum composition stuff in a more coherent paper.
The idea came about, by the way, when I was up at 2 AM watching debug traces of the MIDI guitar pattern matcher ("midime") while I had a fever. I finger pick a lot of fairly fast arpeggios on banjo and guitar, rather than playing full chords, with the melody line brought out by accents. In debugging the traces of the pattern matcher against some phrases I had picked, I found that rather than settle on the discrete chords that were in my head as I played, the arpeggiated timing caused the pattern matcher to weave around in a cloud of chords related to what I thought I was playing, off by a note or sometimes two. The effect was like a probability space centered on my intended chord, with missing or extra notes matched in or out by the matcher. It reminded me of models of electron positions as probability distributions, with no precise, measurable locations, hence the segue to quantum mechanics. Fevers are sometimes good for something
I have since found and read Music and Probability by Temperly, not a bad book, although it focuses on static, non-real-time recognition, not on real-time recognition and improvisation.
Quote:
But on the topic of algorithmic composition it's just that sometimes people claim that they made a musical piece that turns out to be completely algorithmic. I'd say that they crafted the algorithm but simply discovered the mapping from data to notes. It's the rules manipulating the underlying data that create the piece and thus there's no sentient being who made it.
Algorithms are the raw material and it's up to the sentient composer to make the decisions where and how they act. The merit of the composer is that of organizing not of creating melodies.
I agree. And I think anybody who has walked around in this space would honestly have to say that an awful lot of the generated space is dead boring, and the real human trick is to find an area of the generator space that is worth fleshing out. Kassen posted a link to a discussion between Brian Eno and the guy who invented the Sims (Will Wright) series of simulation games over here, and in response to a question about an automated decision maker for throwing out at least 90% of the uninteresting generator space, Eno basically says, "There are plenty of people looking for the hit formula. I could use a few hits myself. If you can write me an algorithm like that, I might use it, but in fact that approach often has the opposite effect."
Yep, I agree that the human composer and performer is an integral part of a loop that can be set up as a tool for the humans. I joke with my wife that my 320 millisecond "canons" on banjo + Live are really a way to give me twenty or thirty fingers in sync with each other, which is sort of the effect you get. I also joke that now I could actually play "Dueling Banjos" against myself, although novelty tunes are not high in my priority list.
You might like this excerpt from the quantum paper.
Quote:
Introduction of a computer performer into a human
ensemble can come from one of two opposing directions. The
computer-driven approach finds the computer imposing
fixed grids of meter, tempo, pitch and compositional
structure onto a performance, constraining human
accompanists to do likewise. “Almost everything people hear
now, certainly in America, is quantized. And so, if you put a
real drummer on, sometimes people don’t get that. They
don’t know how to listen to that alone now. They need that
extra little ... authority of the regular time.” (Battino and
Richards 2005)
Computer-driven performance meets the requirements of
easy software sequencing or corporate valuation of
consistency over quality, but it ignores the superposition of
musical states possible with human performances. It rapidly
binds the set of available superpositional musical structures
into narrowly constrained subsets. Opportunities for fluidity
and performance time creativity diminish.
A computer-collaborative approach constitutes the
alternative direction. The central architectural features of this
approach are both human and computer contribution of
unbound superpositional musical structures available for
entanglement and decoherence during performance, and
human and computer contribution of entangling constraints
that bind a composition at performance time. Both humans
and computers house superpositional musical structures —
practiced compositions and listening and performance skills
in humans, programmed or learned compositions and
analyzing and synthesizing capabilities in computers — that
both can entangle and bind via actual performance. In the
MIDI based computer-collaborative system discussed in this
paper, MIDI guitar playing contributes entangling constraints
that guide decoherence in a software pipeline of processes
that select meter, tempo, tonic, scales, chords, pedal points,
and that match incoming performance data to abstracted
composition traces, binding a superposition of available
musical structures associated with the abstracted
composition. Conversely, accompaniment performed by an
ensemble of software agents driven by this pattern matching
pipeline creates binding constraints that help to determine
where a human performer might go next in the performance.
Initial human playing entangles machine matching and
playing, and machine playing entangles subsequent human
and machine matching and playing in a feedback loop.
Quote:
But hey purely algorithmic pieces are not bad, I'll probably make(I mean discover) a few for the examples to go with PyChucK. (And I really need to start documenting the stuff too. I'm having hard time figuring out my own code already. )
Yeah, I can do OK with my code, but I still occasionally discover interesting sounds and patterns among the bugs, and after fixing the bugs, realize that I have clobbered the sounds and patterns. Twice now with the chess program I have had to go back and re-discover the good stuff, and figure out how to placate the bugs without clobbering the good stuff. And, I am finding out that sometimes they are inextricably linked. Maybe another design principle in that.
For me, discovery and creation are two sides of a coin. Even when I seem to invent something, it feels like discovery. The universe, and especially the human mind-body, are fundamentally mysteries to me.
Have fun. Nice talking with you. _________________ When the stream is deep
my wild little dog frolics,
when shallow, she drinks.
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Sun Jul 20, 2008 9:51 am Post subject:
PyChucK got dynamic. It grew itself some filters and a couple of Lagrange delay lines. I still have a few filters I want to implement but I think I'll leave the Thiran Allpass interpolation for another day.
Still a lot to do, namely support for loading sound files.
EDIT: Python's wave module will do for now for the sound files.
update: I was going to do interpolation of non-uniform data with polynomial splines of arbitrary order but then my head a sploded. :
I'll just leave it to the binary search tree for efficient access and the linear case for interpolation.
So I'm moving up:
Delay lines (static interpolation of non-static data)
Sample tables (non-static interpolation of static data)
Next step:
DigitalTape (non-static interpolation of non-static data of non-static size) _________________ To boldly go where no man has bothered to go before.
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Wed Jul 23, 2008 1:04 pm Post subject:
I just got the first version of DigitalTape up that runs in real time. I had to create a new tape class for the shared buffers to keep things reasonably fast. It means that filling the buffers is not as perfectly convenient as with Python's sequences (no slicing). But the hot thing is that now the sample buffers can be initialized with uninitialized bits from the memory. That's glitchy goodness if you're in to noise or glitch music. Or the next best thing after (destructive) circuit bending at least.
Still a few seq faults to hunt down before I have all the UGens I intended for the beta.
EDIT: One seq fault down. I forgot to initialize a couple of pointers to NULL. My algorithm was running all over the memory following invalid pointers... ouch.
EDIT: Spline interpolating tables are up. :) This implies fast and pitch bend friendly wavetable synthesis. And coupled with numpy it implies fast (almost) bandlimited harmonic additive synthesis. _________________ To boldly go where no man has bothered to go before. Last edited by Frostburn on Sat Jul 26, 2008 3:47 am; edited 2 times in total
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Sat Jul 26, 2008 12:27 pm Post subject:
Because I felt like it... a release.
pychuck.tar.gz
Description:
The first release of PyChucK. No warranties. May crash your box. Very much a work in progress. It doesn't even come with any examples as I haven't got there yet. :)
Joined: Oct 13, 2007 Posts: 6221 Location: near Austin, Tx, USA
Audio files: 270
Posted: Sat Jul 26, 2008 2:22 pm Post subject:
I'm pleased to see the release, but I'll wait for something more stable. How does one run a python program anyway? _________________ "Let's make noise for peace." - Kijjaz
I get rather a lot of errors, so many infact that I had to increase my terminal's history by over a order of magnitude to be able to copy them all. What's going wrong here?
Edit; it seems like that's too many errors for the board to take as well, I'm using a attachment.
errors.txt
Description:
Lots and lots of unsorted errors as I have no idea which bit might be important. Integral copy-paste.
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Sat Jul 26, 2008 3:43 pm Post subject:
Kassen wrote:
I get rather a lot of errors, so many infact that I had to increase my terminal's history by over a order of magnitude to be able to copy them all. What's going wrong here?
Yikes!! That's a lot of errors indeed.
Luckily it's the first ones that matter.
Code:
ugenmodule.c:21:20: error: Python.h: No such file or directory
ugenmodule.c:22:26: error: structmember.h: No such file or directory
You need python's dev libraries. ( python2.5-dev in synaptic )
This is the classic error when building anything from the source. Thank you Kassen for being among the first the experience this with PyChucK.
Inventor wrote:
How does one run a python program anyway?
Python comes pre-installed with most flavors of Linux... You just type "python" in a command prompt and you're in the interactive mode. Or "python myfile.py" to run a script.
I don't know about other platforms though... _________________ To boldly go where no man has bothered to go before.
Thank you Kassen for being among the first the experience this with PyChucK.
Well, it was mainly a test of your instructions, I suppose, I know very little about Python, just that I have it, that it doesn't use braces and your instructions, so I just copied the build command to the terminal like a good little boy. :¬)
I'll try again later, I'm very interested in the possibilities of the interactive mode. _________________ Kassen
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Sat Jul 26, 2008 4:30 pm Post subject:
Kassen wrote:
I'll try again later, I'm very interested in the possibilities of the interactive mode.
Me too.
Although it lags a bit it's still fun and useful.
It's actually the main reason I haven't got any useful example scripts to go yet. I've only been playing with the interactive mode making all kinds of droning sounds while testing if the UGens are working like they should. There's still a lot of this debug live coding to go before I start making anything bigger and song-like and hear what these thousands of lines of code really can do. _________________ To boldly go where no man has bothered to go before.
As long as it's -say- sub-second I don't care that much about lag in compilation, actually a bit of lag might help prevent compilation-induced audio dropouts.
Can you do recordings of your screen and sound? Now that it run it would be nice to see it's development and how your perspective on it develops.
You should probably get on the TOPLAP list if you're not already BTW. _________________ Kassen
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Sun Jul 27, 2008 3:04 pm Post subject:
Kassen wrote:
Can you do recordings of your screen and sound? Now that it run it would be nice to see it's development and how your perspective on it develops.
I'll look in to it.
If I can't reliably capture audio/video while PyChucK runs I should be able to fake it by dumping the audio to disk and splicing in my command line history from single screen captures.
I could also completely fake it by making a script that sporks shreds and just making up a command line history to match that.
We'll see how it goes.
I have nearly 0 experience with that sort of thing myself, but couldn't a simple VCR recorder be used? Assuming you would have a video output on your computer, of course.
BTW, I noticed last week that the free "Spore creature creator" program (a sort of design tool for creatures for a upcoming game) has a build in function to crate videos and upload those to your YouTube account.
This is quite clever as it gets Spore free marketing by the tens of thousands of videos but I could imagine that sort of feature being quite nice for livecoding IDE's. The one great shame is that typically YouTube's compression wreaks havoc on code readability. I could also imagine this being useful to document bugs that might be hard to reproduce though of course it would be useless for bugs that would -say- crash the whole computer or take a lot of CPU. _________________ Kassen
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Sun Jul 27, 2008 4:25 pm Post subject:
I think you could even rig Python to capture the interactive input and make a script that plays that input back, but that's something way in to the future. PyChucK is more like a gas like now in the alpha state. When it condenses in to a beta that sort of thing could be experimented with but only after the program solidifies would I promise that such capture files would play back right between different machines.
A more recent result is that I can load and play back sound files now.
That paves a way to some mad DigitalTape bending.
Also; Listening to bits of the recently deallocated memory is way radical. : _________________ To boldly go where no man has bothered to go before.
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Mon Jul 28, 2008 5:24 am Post subject:
I guess live coding takes some practice to go well... this is way too crude but I'll post it anyway.
The command line history with comments added after the session:
Code:
>>> from chuckoss import * #Load the modules
>>> waveout = WaveOutRaw()
>>> intro = SampleTape("intro.wav") #Hi guys!
>>> amen = SampleTape("amen.wav") #The amen break
>>> amen = amen[0] #Select the left channel
>>> h = DtHead(intro) #Create a Digital Tape Head to read the break
>>> h >> dac >> waveout >> blackhole #Make some connections
<chuck.UGen object at 0xb7bdb2ac>
>>> go() #Start rolling
OSS audio device started. fmt=16, channels=2, sampling rate=44100 .
>>> h.tape = amen #After the intro played it's time for amen break
>>> k = DtHead(amen) #Make another head on the same tape
>>> k >> dac
<chuck.FrameBuffer object at 0xb7b33014>
>>> dac.gain = 0.5
>>> k.rate = 1.2 #Play a little higher
>>> s = SinOsc(1) #LFO
>>> k.end = 20000.0 #Set a loop point for the second head
>>> s >> k.SM #Modulate loop start
<chuck.Gain object at 0xb7bf4134>
>>> s.gain = 10000.0
>>> s >> k.EM #Modulate loop end
<chuck.Gain object at 0xb7bf418c>
>>> s.gain = 300000.0 #Oops this was a bad idea
>>> s.freq = 0.2 #A little better
>>> w = DtHead(amen) #Make a writing head
>>> dac >> w #Feedback
<chuck.DtHead object at 0xb7d3d9ac>
>>> w.rec = 0.5;w.feedback = 0.5 #Set up how to write
>>> w >> blackhole #Start writing
<chuck.UGen object at 0xb7bdb2ac>
>>> j = DtHead(intro) #A reading head for the intro
>>> j >> dac #It's more of an outro now.
<chuck.FrameBuffer object at 0xb7b33014>
>>> j.rate = 3.0 #This was a bit much
>>> w.rate = 2.0
>>> j << dac
<chuck.FrameBuffer object at 0xb7b33014>
>>> w.rec = 2.0 #Oops, I broke it
>>> w.rec = 0.0 #Well that ain't going to fix it
>>> stop() #I guess I'll have to stop the session then
Stopping thread...
>>> waveout.close() #Save the session
>>> "Thanks"
'Thanks'
pychuck-amen-session.ogg
Description:
The output generated from the session.
Filesize:
1.49 MB
Viewed:
873 Time(s)
_________________ To boldly go where no man has bothered to go before.
I guess live coding takes some practice to go well...
Of course it does! Any instrument does.
I think this is downright obvious (it would be quite disturbing if practice didn't help), but Nick managed to look at practice for livecoding in more depth and his paper on it is quite interesting.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
Forum index » DIY Hardware and Software » ChucK programming language
FAQ
Calendar
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Chat Room
, but leaving some interesting parameters unbound until performance time, and some of them non-deterministic from the performer's point of view.
)
:
: 