| View previous topic :: View next topic |
| Author |
Message |
paniq
Guest
|
 Posted: Sunday February 6th, 2005 19:09 Post subject: PyBuzz |
 |
|
Just to let you know that PyBuzz has been updated with some new cool peer controller shit! *triggers hydraulics* w00t w00t
http://buzzwiki.wipe-records.org/index.php/PyBuzz
Last edited by paniq on Tuesday February 8th, 2005 4:28; edited 1 time in total |
|
| Back to top |
|
 |
btd
Cardinal
Joined: 13 Aug 2004
Posts: 765
Location: York, UK
|
| Posted: Sunday February 6th, 2005 21:36 Post subject: |
|
|
 An awesome machine just got awesome-er!
Only one little bug to report: drag and drop parameter assignment probably won't work on versions of Windows different to yours. That's because you've identified param sliders by class names. In particular Afx:400000:0:10013:0:0 needs to be changed to Afx:400000:0:10011:0:0 to work on Windows 2000. There could be other dependencies causing them to be different on the same OS as well, I've no idea. Maybe you could just switch to a more reliable method of identification (I think all param sliders are easily identified by the window title "paramslider", but spy++ it to make sure).
When I got it working, drag and drop assignment gave me a major "I wish I'd thought of that" moment  The icing on a yummy python-flavoured cake. |
|
| Back to top |
|
|
intoxicat
Archbishop
Joined: 20 Aug 2004
Posts: 501
Location: Brighton , UK
|
| Posted: Sunday February 6th, 2005 23:39 Post subject: |
|
|
| yep -doesnt seem to work on XP.... but a great idea nonetheless |
|
| Back to top |
|
|
usr
Pope
Joined: 12 Aug 2004
Posts: 1156
Location: nuremberg, franconia, germany, europe
|
| Posted: Monday February 7th, 2005 2:19 Post subject: |
|
|
getting the parameter names into the param picker gui worked on my 2k box. probably some lib version issue then?
_________________
.nl chefs go blok blok blok |
|
| Back to top |
|
|
paniq
Guest
|
| Posted: Monday February 7th, 2005 10:35 Post subject: |
|
|
very strange. so that slider box gives different values for the classname. 
thanks for your help.
i checked again and found out that i was a bit stupid. all slider windows have "sliderparam" as window text, so its more than easy to find those.
a fix will soon follow. |
|
| Back to top |
|
|
paniq
Guest
|
| Posted: Monday February 7th, 2005 10:35 Post subject: |
|
|
| of course its "paramslider" not "sliderparam" |
|
| Back to top |
|
|
paniq
Guest
|
|
| Back to top |
|
|
paniq
Guest
|
| Posted: Monday February 7th, 2005 11:01 Post subject: |
|
|
whoops btd said it already
btd: the source is included. you are free to extract the neccessary functions and classes and use them in your own peers.
i am working on pybuzz 2.0 now which is based on the 1.4 code, overcoming a few limitations like
- each script runs in non-shared interpreter environment
- script syntax is not object-oriented and rather flat, functions have to be registered instead of creating classes with virtuals
- audio mixing is not possible
- pattern and parameter layout is fixed
2.0 will not be backward compatible and released with a new machine name, so nothing will break and 1.4 can still be used to script peer applications. 2.0 is for writing complete machines in python to prototype things or to just play around. you can only load one script per buzz session.
1.4 is for quick and dynamic scripting sessions and easier to debug and write. |
|
| Back to top |
|
|
btd
Cardinal
Joined: 13 Aug 2004
Posts: 765
Location: York, UK
|
| Posted: Monday February 7th, 2005 12:11 Post subject: |
|
|
Works great for me now! The Windows version theory was just a guess, as that seemed to be the cause the last time I saw this problem. I guess the cause is just some random MFC strangeness.
Pybuzz 2.0 sounds very cool. Is python fast enough to do reasonably involved DSP? |
|
| Back to top |
|
|
paniq
Guest
|
| Posted: Monday February 7th, 2005 13:28 Post subject: |
|
|
| btd wrote: |
Pybuzz 2.0 sounds very cool. Is python fast enough to do reasonably involved DSP? |
my guess is: no. however i can imagine that using psyco or some high level functions for mixing and other stuff (basically just applying c++ methods on buffers instead of doing it all on your own) wont be much slower than c++
i did a benchmark.
| Code: |
>>> def dodsp(fb):
... for i in xrange(len(fb)):
... fb[i] *= 0.5
...
>>> def bm(f):
... fb = [1.0]*256
... t1 = time.time()
... for n in xrange(100000):
... f(fb)
... t2 = time.time()
... print t2 - t1
|
the dsp innerloop code scales the volume of a 256-element buffer filled with 64bit floats by 0.5
this code is then executed 100.000 times recursively.
on an AMD Athlon XP 2800+ (approx 2Ghz) the above benchmark needed ~8828ms, which is 0.08828ms per buffer.
with a sample rate of 48000 samples per second, the dsp routine has to be executed 187.5 times, needing about 16.55ms per second to calculate the new buffer.
| Code: |
>>> def dodsp2(fb):
... for i in xrange(len(fb)):
... fb[i] *= 0.5 + 0.5
|
above code needed approx 11200ms, which is 21ms per second for 48khz.
| Code: |
>>> def dodsp3(fb):
... for i in xrange(len(fb)):
... fb[i] *= 0.5 + 0.5 + 0.5
...
|
above code needed 14094ms, which is 26.43ms per second for 48khz.
every operation (+,-,*,/) gives an overhead of 5ms per second, simply for object allocation, reference counting, and so on. |
|
| Back to top |
|
|
usr
Pope
Joined: 12 Aug 2004
Posts: 1156
Location: nuremberg, franconia, germany, europe
|
| Posted: Monday February 7th, 2005 13:52 Post subject: |
|
|
how would this be any different than controlling a pack of champs?
(assuming subtick peer controllage)
_________________
.nl chefs go blok blok blok |
|
| Back to top |
|
|
paniq
Guest
|
| Posted: Monday February 7th, 2005 14:01 Post subject: |
|
|
i dont understand the question.
more benchmarking:
i installed psyco, a JIT compiler for python, and applied it to my functions
| Code: |
>>> import psyco
>>> psyco.bind(dodsp)
>>> psyco.bind(dodsp2)
>>> psyco.bind(dodsp3)
>>> psyco.bind(bm)
|
now all three functions return something around 921ms, which is 1.727ms calculation time per second.
in other words: with psyco, doing dsp with python machines is indeed possible. |
|
| Back to top |
|
|
mute
Angel
Joined: 13 Aug 2004
Posts: 3361
|
| Posted: Monday February 7th, 2005 22:24 Post subject: |
|
|
so you're going to add an effect version soon?
I was thinking about this yesterday after we finished talking. I figured python would be too slow for DSP (or not, apparently) but I thought of some other ways that PyBuzz could work as an effect.
Have it contain code to pick up amplitude/env/gating/ and maybe midi data from connected machines, then expose this data to the scripting.
the midi in particularly would be a cool filter, because w/ python we can do some serious midi code/event stuff. the amp/env is less cool because we can basically already do that by assigning a peer env or peer trigger to pybuzz, but it would definitly be better and more beefy ;]
basically im thinking of something like this:
eg:
amplitude(db?) = GetInput(x[a])
midi array = GetInput(x[b]) etc...
(or whatever)
Oh man. You should _definitly_ add Multi-out if you make an effect version. DEFINITLY ;] Conditional routing/mixing. MMMMMnnnn.
random idea: maybe some built in lowcpu effects in pybuzz could be exposed in the code? like a simple 1p LP/HP filter, etc?
the fact that the Python console (command) doesnt have to be shown anymore really makes this so much cooler.
usr: this would be nothing like just using a PeerCtrl on a bunch of ch.amps unless you have an extremely limited imagination ;]
for example, think thresholds meets audio and peer control values in one.
peerctrl is just simple click+control, pybuzz is scripted conditions, value comparison, midi data, all kinds of whack shit ... ;]
nevermind the GUI stuff you could do if you wanted to, or user interaction, or any other # of things.
_________________
http://www.lazytrap.com/ |
|
| Back to top |
|
|
mute
Angel
Joined: 13 Aug 2004
Posts: 3361
|
|
| Back to top |
|
|
paniq
Guest
|
| Posted: Tuesday February 8th, 2005 3:52 Post subject: |
|
|
| mute wrote: |
random idea: maybe some built in lowcpu effects in pybuzz could be exposed in the code? like a simple 1p LP/HP filter, etc?
|
thought about that. some basic often-used dsp routines should be included, however i'm not the dsp guy, but i will happily include any contributions. |
|
| Back to top |
|
|
paniq
Guest
|
| Posted: Tuesday February 8th, 2005 4:28 Post subject: |
|
|
I applied for a sourceforge directory, here is the project description i submitted.
| Quote: |
The software is already done and public, being at version 1.42 at the time of application.
The software has been developed in Visual Studio .NET 2003 and requires WTL 7.0 to be built.
The software requires Windows 98, Windows 2000 and Windows XP and does also run with Linux using Wine. Furthermore, an installation of the free Buzz Modular Tracker, a music program, is required (homepage is http://www.buzzmachines.com).
The development of Buzz, a closed source software, has been closed in 2001 when a major harddisk crash occured to its sole developer Oskari Tammelin. Since then, the program has been majorly extended by hacking the binary from the outside, providing new functionalities such as peer controlling (algorithmically manipulate parameters of generators and effects) a feature that has not been planned or implemented for the original version of Buzz.
PyBuzz brings a new feature to Buzz which is scripting support. It allows musicians and music scientists to rapidly incorporate libraries exposed to python, thus opening the door for networking support and other technologies not yet exploited by the application.
Furthermore, from Version 2.0 on, DSP support (generating and mixing audio data) is planned, using the Psyco lib which is also hosted here on sourceforge to speed up computing time.
There are no technical problems with the project. PyBuzz has been successfully realized and is awaiting further improvements.
Major features included in the software:
- allows to extend Buzz with scripts
- python support
- works as plugin
- psyco support
- DSP support (planned)
The projects website is currently a wikipage in the Buzz wiki at
http://buzzwiki.wipe-records.org/index.php/PyBuzz
The most recent release (source code included) can be downloaded from there.
|
|
|
| Back to top |
|
|
btd
Cardinal
Joined: 13 Aug 2004
Posts: 765
Location: York, UK
|
| Posted: Tuesday February 8th, 2005 15:12 Post subject: |
|
|
| mute wrote: | | Oh man. You should _definitly_ add Multi-out if you make an effect version. DEFINITLY ;] |
Oh yeah! Multi in as well. And there should be a multi-out generator version too, to get rid of the evil dummy generator if we want to play with synthesis.
Actually what would be really cool is if pybuzz 2.0 scripts could be compiled to a real, native buzz machine dll (or as close to a real, native dll as possible). Then the pybuzz machine would be for prototyping and testing (hopefully with the ability of 1.x to reload scripts without quitting Buzz), and then the same code could be compiled to a fast, releasable machine. Dunno how feasible that is.
| mute wrote: | | random idea: maybe some built in lowcpu effects in pybuzz could be exposed in the code? like a simple 1p LP/HP filter, etc? |
Looking at those benchmarks for psyco, I don't think simple IIR filters would be too much trouble in plain python actually. Not sure I'd like to try doing a "fast" Fourier transform though...
Actually doesn't python have some groovy system where libraries can be written in c++ and called from a python script? In which case the heavy DSP stuff wouldn't even need to be included in pybuzz. I bet there are DSP-ish pyton modules already out there if you look.
| paniq wrote: | | peer controlling (algorithmically manipulate parameters of generators and effects) a feature that has not been planned or implemented for the original version of Buzz. |
Not strictly true, but close enough  |
|
| Back to top |
|
|
paniq
Guest
|
| Posted: Tuesday February 8th, 2005 15:59 Post subject: |
|
|
| btd wrote: |
Oh yeah! Multi in as well. And there should be a multi-out generator version too, to get rid of the evil dummy generator if we want to play with synthesis.
|
i have no idea how multiout works. give me docs.
| btd wrote: |
Actually what would be really cool is if pybuzz 2.0 scripts could be compiled to a real, native buzz machine dll (or as close to a real, native dll as possible). Then the pybuzz machine would be for prototyping and testing (hopefully with the ability of 1.x to reload scripts without quitting Buzz), and then the same code could be compiled to a fast, releasable machine. Dunno how feasible that is.
|
impossible. needs a python -> c++ converter, good luck on that subject. pyrex might be able to do it but i have no experience with that and i feel already convenient with a machine i can script.
| btd wrote: |
Looking at those benchmarks for psyco, I don't think simple IIR filters would be too much trouble in plain python actually. Not sure I'd like to try doing a "fast" Fourier transform though...
|
write a python extension module in c++: there you go.
| btd wrote: |
Actually doesn't python have some groovy system where libraries can be written in c++ and called from a python script? In which case the heavy DSP stuff wouldn't even need to be included in pybuzz. I bet there are DSP-ish pyton modules already out there if you look.
|
exactly. there is also socket support. we could do fancy networking stuff.
| btd wrote: | | Not strictly true, but close enough |
okay, there is some kind of peer controlling but uhm its sucky |
|
| Back to top |
|
|
btd
Cardinal
Joined: 13 Aug 2004
Posts: 765
Location: York, UK
|
| Posted: Tuesday February 8th, 2005 17:39 Post subject: |
|
|
| paniq wrote: | | i have no idea how multiout works. give me docs. |
Your best bet is probably to use Polac's multi out system. So Frank is the guy to get in touch with for docs.
| paniq wrote: | | impossible. needs a python -> c++ converter, good luck on that subject. pyrex might be able to do it but i have no experience with that and i feel already convenient with a machine i can script. |
Never mind then. I just thought I'd mention it in case the technology already existed (I thought if you could compile python right down to machine code somehow, and inject that code into a "blank" dll previously compiled with vc++, that would do it --- but that relies on python->machine code being possible).
I guess it's convenient enough without this. I was just thinking about what you said here:
| paniq wrote: | | 2.0 will not be backward compatible and released with a new machine name, so nothing will break and 1.4 can still be used to script peer applications. 2.0 is for writing complete machines in python to prototype things or to just play around. you can only load one script per buzz session. |
If you really do want to write full-blown synths and effects in pybuzz, that limitation might be a bit annoying (assuming I've read it right --- that limitation will be in v2.0, either by design or by necessity, right?) |
|
| Back to top |
|
|
paniq
Guest
|
| Posted: Tuesday February 8th, 2005 17:53 Post subject: |
|
|
| the problem is that buzz does not allow different parameter settings per machine. i guess pybuzz 2.0 will still not allow modification of parameter structure so that there is no confusion, but i'll release something different (planned t o be called "pymachine") which is a 1-machine-host for exactly one application, with custom parameters. |
|
| Back to top |
|
|
paniq
Guest
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
