Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Mon Jul 28, 2008 2:22 pm Post subject:
Well that was just a quick try out to see how it goes.
It goes badly.
By the way did you try compiling the thing with the python-dev libraries installed? I'd just like to know that it runs.
EDIT: We've got stereo panning and a panning modulator to go with that.
Luckily I could do multichannel in pure python with customized UGens so that the C extension module only has to understand mono streams.
EDIT2: I made a new ComplexUGen class purely in python... It's not nearly as fast as it could be if I pushed it down to the C module but it's more of a curiosity anyway. _________________ To boldly go where no man has bothered to go before.
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Sun Aug 03, 2008 5:42 am Post subject:
Progress is slow and I'm running into old brain farts that looked good on paper but don't actually work in practice.
Also most things are made with quick hacks (causing security issues) and need to be redone for the beta. (so boring)
Another thing is that Python 3 is coming out so I'm facing a rewrite anyway.
Progress will probably slow down even more when school starts next month.
Good thing I haven't advertised PyChucK much outside this thread.
Well anyway... I got a Karplus-Strong waveguide working... it could use some optimization though. _________________ To boldly go where no man has bothered to go before.
It's a list of tuples and the names of the durations and pitches are pretty standard.
The first item of a tuple is the duration of the note.
The second item is the pitch/pitches of the sound.
The third item is the note on velocity.
The fourth item is the duration of the sound.
The fifth item is the note off velocity (abruptness of the release).
pychuck_guitar_test.mp3
Description:
A quick test with the Extended Karplus-Strong algorithm making guitar sounds.
Filesize:
196.85 KB
Duration:
0:13
Viewed:
1680 Time(s)
_________________ To boldly go where no man has bothered to go before.
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Tue Aug 05, 2008 9:31 am Post subject:
Oh why didn't I try this earlier...
PyChucK is too heavy to handle shreds that advance time one sample at a time. This severely limits what shreds can do and my motivation just plummeted... _________________ To boldly go where no man has bothered to go before.
Joined: Jul 07, 2007 Posts: 2082 Location: Berks County, PA
Audio files: 90
Posted: Tue Aug 05, 2008 10:34 am Post subject:
Frostburn wrote:
Oh why didn't I try this earlier...
PyChucK is too heavy to handle shreds that advance time one sample at a time. This severely limits what shreds can do and my motivation just plummeted...
I think you'd have to have Python build C-level signal flows (via the C API), and have a C (or C++) thread running to pump data through the signal flow. Python libraries basically help to configure (architect) a set of interconnected signal flows, which Python passes off to C/C++ land for a) final construction, and b) data pumping.
I guess ChucK does something like this. This is fairly typical for DSP applications, using some higher level language to build and glue, and a lower level, more efficient language to do the heavy lifting. On some small footprint hardware DSPs, C programs and libraries are actually the "high level" gluing environment, and DSP assembler does the run time heavy lifting. That is evolving, but an awful lot of embedded DSP designers build the heavy lifting part in DSP assembler and application-specific ICs.
It's not a bad idea, though, to do something like this in Python. I've done this sort of thing for simulation engines using Tcl instead of Python -- simulations running in C threads underneath a Tcl interpreter that interacts with users. Substitute Python for Tcl and a music signal flow construction API for a simulation data flow API. It is a time consuming undertaking.
Have fun. _________________ 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: Tue Aug 05, 2008 11:57 am Post subject:
The UGens are actually just C level signal flows that are glued together with Python calling ">>" between them.
On the bright side getting shreds to perform on a sample-by-sample basis isn't too critical as most time domain things can be done with waveshaping and filtering.
It was the frequency domain that's causing trouble because with my approach to additive synthesis you have to supply information about the partials' frequencies and magnitudes every 256 samples or so. I'm aware of additive synthesis methods that need data more scarcely but they're only good for slowly evolving pads.
For the solution I'm thinking about expression objects that could abuse Python's parsing capabilities and be compilable to fast C level objects that would in turn drive the additive synthesizer.
EDIT: Hmm... maybe I could extend digital tape to a more general array or just use numpy's array interface for block processing. If numpy isn't ready when Python 3 comes out I'll have to make my own. _________________ To boldly go where no man has bothered to go before. Last edited by Frostburn on Wed Aug 06, 2008 3:09 am; edited 1 time in total
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Thu Aug 07, 2008 2:35 am Post subject:
I think the smartest way to go is to extend digital tape to a general python sequence with numpy.array like capabilities. I'll also move the random access interpolation code from the digital tape head UGens to the tape itself.
That way a DigitalTape object can be a fast internal buffer for sample data, a flexible pythonic sequence, a fast block processor of analysis data and an interpolating function.
The data type will be restricted to 64bit doubles. (The default data type for PyChucK samples)
The tape can be circular or not. This affects the range of valid access indices and interpolation near the end points.
The tape will have a sampling rate so that durations can be used to access the samples.
There will also be a read only FrozenTape object that precalculates the interpolation coefficients. A read/write piecewise polynomial tape should do.
EDIT: I've been playing around with a mock implementation of Digital Tape and it slices, splices and stretches nicely so far. But it's no good for analysis data. Numpy already did that in a better way. (I got harmonic additive synthesis to work in real time with numpy.) _________________ To boldly go where no man has bothered to go before.
Joined: Feb 25, 2008 Posts: 45 Location: Vancouver
Posted: Tue Aug 12, 2008 1:12 am Post subject:
Frostburn wrote:
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.
Just out of curiosity, how much trouble would it be to implement PyJack: http://sourceforge.net/projects/py-jack/ into PyChuck? It would be very useful as some soundcards (such as firewire devices) are only loaded through jack. I've yet to even download pychuck yet, so I might be able to figure this one out on my own. Is PyJack suitable for a task such as this or did you already look into it and conclude it wasn't?
Edit: after a (very little) bit of my own reading I've found what you speak of in the PyJack readme file
Quote:
3. Capture X seconds of audio (jack.process)
4. Process audio using your algorithm
It does not matter how long this takes...
5. Playback X seconds of audio (jack.process)
6. Detach from jack server (jack.detach)
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Tue Aug 12, 2008 8:04 am Post subject:
Stochastic wrote:
Is PyJack suitable for a task such as this or did you already look into it and conclude it wasn't?
I did take a quick glance over PyJack but as far as I could tell it wasn't for real time audio synthesis. Just for separate capture - process - playback sessions.
If PyJack can be modified for real time synthesis or converted to a blocking audio device module then it could be merged with PyChucK.
I haven't tried the merge yet because PyJack uses an outdated version of "numerix array" and it must be replaced with numpy.array or something else.
I may take another chance with Jack when Python 3 comes out and it's time to rewrite PyChucK anyway.
But I'll probably look into RtAudio first. _________________ To boldly go where no man has bothered to go before.
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Mon Aug 25, 2008 2:03 pm Post subject:
I took a little break from developing PyChucK. (blame Guitar Hero: On Tour for Nintendo DS)
But now that Python3.0 beta 3 is out I could start the rewriting process.
And sorry for not capturing any interactive coding sessions. PyChucK just isn't ready for that yet... _________________ To boldly go where no man has bothered to go before.
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Mon Aug 25, 2008 2:46 pm Post subject:
Inventor wrote:
I was wondering when you were going to take a break! I mean, you're only human right?
Human schuman. Sanity is overrated.
Um....
Yeah. I really needed a break.
I just happened to run in to pyalsaaudio. It doesn't have MIDI support (yet) but it looks good. I'll give it a spin and see if it can do capture. _________________ To boldly go where no man has bothered to go before.
Joined: Dec 24, 2004 Posts: 2523 Location: San Jose, California
Audio files: 2
G2 patch files: 1
Posted: Mon Aug 25, 2008 2:53 pm Post subject:
Frostburn wrote:
Oh why didn't I try this earlier...
PyChucK is too heavy to handle shreds that advance time one sample at a time. This severely limits what shreds can do and my motivation just plummeted...
Have you tried psyco or Pyrex to improve performance-critical areas?
Oops- Just saw you were using or thinking of using Python 3- psyco will not work with Python 3000, don't know about Pyrex though _________________ Free Tibet. Release the Panchen Lama from prison. Let the Dalai Lama return to his home.
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Mon Aug 25, 2008 3:15 pm Post subject:
I looked in to Pyrex but then I decided to do PyChucK in C.
Doesn't help with the shreds ticking at sampling rate problem though. It's related to Python's inner workings and stuff (especially stuff). I should be able to circumvent the problem with sample arrays and a sound buffer though. _________________ To boldly go where no man has bothered to go before.
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Wed Sep 03, 2008 10:58 am Post subject:
Progress has been slow because I've been tweaking my fast additive synthesis method based on IFFT.
The fractional interpolation scheme I was using didn't produce good partials in the low end of the spectrum. Luckily I finally realized (after reading about chirplets) that I could spread the partials in the frequency domain using a gaussian window and then just divide that window away after transforming to the time domain. It might be possible with other kinds of windows but the gaussian is easiest to use becuase it's fourrier transform is another gaussian.
I'm currently using 14 FFT bins per generated sinewave partial. I'll try to bring that number down a bit...
EDIT: Blackman window needs about 9 FFT bins/partial and it's doesn't need rewindowing for cross fades with 4x overlap. Pretty cool.
EDIT2: Too bad this method doesn't do pitch bend well... I guess it's time to look at those chirplets... _________________ To boldly go where no man has bothered to go before.
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Wed Sep 24, 2008 11:57 am Post subject:
I'm running into nasty bugs and instabilities and school takes it's time but I'm moving crawling towards some kind of "proof of concept" version so that I can at least release something sometime.
The main instability comes from the interactive mode which isn't behaving as nicely as I had hoped. The main issue is that it isn't thread/shred safe. It wreaks havoc when I change numpy array sizes on the fly and only some of the arrays resize and some don't.
I may actually be doing this the wrong way around. Instead of re-inventing ChucK in Python I might've been better off embedding Python in ChucK. _________________ To boldly go where no man has bothered to go before.
I *was* wondering about that. It wasn't clear to me why you didn't simply borrow all of the UGens, the way the Ugen graph works, probably the shreduler as well and put your Python syntax (and probably way of dealing with existing data as well) in that.
The big problem might be butchering the whole thing up that badly and still keep Python's way of updating while running. That seems to be the big question; Ge hasn't solved that for plain ChucK either. _________________ Kassen
Joined: Dec 12, 2007 Posts: 255 Location: Finland
Audio files: 9
Posted: Wed Sep 24, 2008 12:49 pm Post subject:
Kassen wrote:
I *was* wondering about that. It wasn't clear to me why you didn't simply borrow all of the UGens, the way the Ugen graph works, probably the shreduler as well and put your Python syntax (and probably way of dealing with existing data as well) in that.
It had more to do with "I want to see if I can do this all by myself all from scratch" than "reasonability". I also do not completely understand ChucK's source and I needed to practice on something. _________________ To boldly go where no man has bothered to go before.
Joined: Oct 24, 2008 Posts: 8 Location: Charleston, SC
Posted: Fri Oct 24, 2008 10:04 pm Post subject:
Frostburn wrote:
Kassen wrote:
I *was* wondering about that. It wasn't clear to me why you didn't simply borrow all of the UGens, the way the Ugen graph works, probably the shreduler as well and put your Python syntax (and probably way of dealing with existing data as well) in that.
It had more to do with "I want to see if I can do this all by myself all from scratch" than "reasonability". I also do not completely understand ChucK's source and I needed to practice on something.
You know, being able to access even a subset of ChucK through Python syntax (either embedding Python within ChucK or the other way around) would be really useful. I am thinking of a CS1-level class in Computer music -- having access to the gentleness of Python syntax for any music making framework would be SO motivating to students. (The ChucK syntax is killing them.) A wonderful service to the community, IMHO, even if partial.
It is? That's not good.. part of the plan behind ChucK is that it should be accessible, it should actually be accessible to people who never programmed anything or wrote any music before. The PLORK/SLORK/etc people have been booking very interesting results there so I wonder what's going wrong here. _________________ Kassen
Joined: Oct 24, 2008 Posts: 8 Location: Charleston, SC
Posted: Sun Oct 26, 2008 1:59 pm Post subject:
Kassen wrote:
Welcome on board!
manaris wrote:
(The ChucK syntax is killing them.)
It is? That's not good.. part of the plan behind ChucK is that it should be accessible, it should actually be accessible to people who never programmed anything or wrote any music before. The PLORK/SLORK/etc people have been booking very interesting results there so I wonder what's going wrong here.
Thanks, glad to be on board!
Don't get me wrong. I was besides myself when I discovered ChucK and what one could easily do with it (e.g., hid).
But, unfortunately, that's my observation. Perhaps I am the exception to the rule. I was really excited about it, so were the students, until we started diving into some of the examples. The fact that ChucK follows a C++/Java like syntax is not helping. Hence, my posting above about Python.
Here are two examples of small (for me, but not my non-programmer students) issues with consistency:
Why '@=>' vs. '=>'? (Why not overload '=>' once more, and introduce a copy() operator?)
Another example:
SinOsc x => dac;
SinOsc y => dac;
440 => x.freq;
x.freq => y.freq; // error! x.freq is actually a function.
(If hiding the fact that SinOsc.freq() is a function, why not overload it, so that when called without arguments it returns the current frequency? Also, hide in the documentation the fact that SinOsc.freq() is a function.
Or even better... why doesn't '=>' bind the two frequencies together?)
Again, don't get me wrong - I really like ChucK for what it can do so easily. I was thinking perhaps that having Python bindings would allow one to create a more accessible API subset for beginners.
Thanks again for the welcome. I hope I have not lost all grace with my comments...
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
