Pydrum v. 0.1
Copyright 2007
By Michael Collins, aka dukajoe
Questions comments: look to buzzchurch forum or email at dukajoe@yahoo.com


Your favorite forum jackass here, bringing you a midi implimented tertiary sequencing system for buzz. You may say, why do I need another way to sequence beats? I made this for three reasons:

1. It's intended for live use. You can use a midi controler to call a sequence via interruption or qeueing, and have it play right then. So basically, if you are using buzz for beats or using a second buzz instance for stuff you can improv and use effects in real time.

2. You can do whatever kind of beat you want. I see posts all the time about "how can I do 7/8's time then switch to 5/4 ect., and sure there are ways to do this, but its not very intutive, and its certainly not easy to impliment live. With pybuzz, you have to make an effort to not make off time beats, and since it is in no way tied to the main sequencer, you can do whatever you want and have it loop. You could have a bassdrum 40 ticks in length, a snaredrum track 39 ticks, and it would take 40 measures for them to catch back up with eachother!

3. Can have a database of beats. You could have many sequences defined in a file then mix and match them easily during a live performance ect. You can also do much more than beats if you wanted, i.e. note sequences. You can adjust the length to any tpb as well.


This all works by creating drumtracks and auxilary tracks. Drum tracks are one per instance of the class, and they are sequences which directly control the beats of a track on samplegrid, and you generally assign these by bassdrum, snare ect. You can use a length multiplier, so that if you double the tpb of a bmx, you can double the track lenmultiplier to keep up with the beat. Auxillary tracks can control anything on any other machine, you just have to assign it to it, and you can make any number of tracks per class instance. You could have one drumtrack, then control the entire rest of a song with auxilaries. Still, I generally intend for them to use things related particular class instance. 
These have the following formats:
track / aux = [valueone, valuetwo]
Specifically,
Track = [0, 1] or [0, 2] ect. You would think that 0, 1 would make 0, 1 track, but it actually makes 1, 0. 0 means trigger on that tick, and anything higher is the number of rests. so 0, 3, would translate to 1, 0, 0, 0
aux = [0, -2, 200, -1000, 10, 20, -5, 5, -1000] One track controls all auxes. Zero or greater is a track value. A negative number is the number of rests. -1000 is track divider, such that before this, it will control the first track, and then afterwards it will control the next track, for any number of tracks. You have to have -1000 at the end of each defnition. 
You can see this implimented, along with some functions in the file imported with buzz. 

Installation:

Requirements:
Buzz
Pybuzz
Python 2.4
Newest Samplegrid2 beta (061110). You don't have to use this, although that's what its currently built around.
some midi controller, or polac vsti midi, ect

Just unzip the file somewhere and put pydrumlib.py in your site-packages folder in the python installation. When you open the bmx file to see the example, say yes to the excute script thingy. The file uses polac vsti as the midi controller, so when you open the bmx file, open the midi out controller selectable in the pvsti machine menu (i think any of them will work), and it should work ok. Press play once you've done that, then the notes the machine plays will control drum sequences.

Eventually, you'll want to set up your own file with drumbeats etc, and use a different kit ect. I can provide more documentation later. 

Buze Support: Not sure. I know the demo file does not work in buze, and this is because, the midivst.dll does not work without the polac asio drivers. But, I bet if you get a midi controller, and just try it that way, then it would work fine. I'll try this myself when I get another minute.

Bugs / things to add / fix, in order of most pressing / easiest to fix to difficult / crazy ideas:

- Number of aux channels has to be fixed in the beggining with the fill aux function. Want to have to where you can chnage the number of auxes dynamically while the script is executing, although you can change the targets whenever

- It's a tick off :(   You have to tell it to do something a tick ahead of time, unless you have a track queued, and then you can press it well ahead in advance, and it will come in on time. Not sure if this is possible to fix or not. May end up have a user setting for tick latency

- re-importing the script behavior is a little off. It sets wierd targets, fills in the plaes that aren't supposed to be filled with tracks for samplegrid triggers


- queuing mechanism, right now doesn't work totatly well, and I want to have it to where you can press 4 notes really fast, and you have the next 4+ measures planned out

- Auxilary track length multiplier

- global interrupt feature does not currently work because I had to fix a bug and disable it, or rather, it doesn't fuction cause it and a couple of other random things are bypassed, so...

- don't like the -1000 aux separator. I wanted to have multiple aux lists within lists, but im not good enough at python yet to do this

- definately need some time of grouping mechanism. For example, if you want to queue to start a snare track, it will start when its track when it's done playing, not when the rest of the tracks are supposed to start. Cool behavior, but it would be nice to get the tracks synced at some point. This works in reverse, i.e. you can interrupt already playing tracks together, all at once

- need to, in general, put more into library, and less into implimentation. I could make drumtrack declarations fillblank and settarge automatically with ease, but I want to do this on a wider scale, and for bug testing and feature exploration

- GUI. Don't know where to begin with this :P 

- Moreover, Machinenize. Make it like any other peerctrl machine. Don't care to at this juncture, but soon.

- Access SQL. T'would be neat to have a sql server running to store arrays and such, and then if you were playing with other people, you could have a central database to access and edit realtime for which all musicians could use.

- Forecasting. Be able to predict / make up drum beats bassed on past values. Could do this right now, but what comes out of the speakers is another thing. Definately not pressing, and to do it right, I'd have to use FANN models, which is a little bit more difficult to do. 







