Repeat last bar of random midi events?
Ive gor random notes velocity and duration going, how would I go about capturing the last bar or 2 and repeating them? Maybe seq~ or is there a better way?
I've wondered that before too. (Personally, I've been calling it a midi "pattern recorder").
Luckily though, seq~ seems to work pretty well for this. Also, I think monome folks use seq~ for their pattern recorders.
The difficulty with seq~ is it's a little cryptic, a little hard to work with the data. The point I got stuck at, was trying to quantize the notes.
If you want, I can post what I got...
I havent tried it yet but I watched an old max video about it and it seemed kinda arduous to work with which is why I came here first.
If the incoming notes are already quantized is it pretty straight forward from there?
I think the main thing here is that (what I think you're doing is) you're generating random values as you go, correct? Each new request for a note gets somehow randomized?
What I typically do is use uzi to generate a randomized list of sorts, and walk through that (multislider using "fetch $1", for instance)
If you do it like that then it's suddenly easy to do noisering-type pseudo-random sequences.
I made a hub that sends a random bang to one of 8 tracks with a note dropout probability. Each track recieves the bang and creates a random note with random velocity and duration with a bunch of faders for random amount and offset. Now I just lack the ability to loop 1 or 2 bars on the fly.
Your noisering idea is cool but if Im not mistaken that would not retain timing of incoming events am I right? If not then it would be useful in a different scenario.
This may or may not be useful in your case, but you can "seed" the random function so that it produces a replicable sequence of random values.
My point is that this "hub o' randomness" could come *downstream* from a sequence of your making - instead of having "random bangs" you can *generate* a stream of your own randomization, and loop *that* instead.
...but at any rate it'd be difficult to say anything more specific without seeing the patch.
The underlying point is that for this to work you either have to "record bangs" and play back a recording, or have a more lateral approach to randomized bangs moving through a patch.
Def food for thought wetterberg. Ill play with it at any rate just for the learning. If it doesnt get me exactly where I was going Im sure itll get me somewhere interesting :)
Seq~ is not too hard, if you just want a simple midi recorder. Look in the help file under the "midi" tab. Set your phasor~ to sync to one bar, and hook it up to rate~ set to two.
Cool Ill look into that.
Dumb question, when and why is it best to use a phazor~ instead of a metro? Im guessing cause metro gives a tick for time and phazor~ moves an object through time? I know that terminology is probably way off and I should probably just start reading...
Phasor~ is better, one because it's audio rate. But also phasor~ outputs 0. to 1. which is what seq~ needs...
I tried phazor~ but failed to get it to sync to my liveset ended up getting sync~ to work but only at 1bar max length. Got the seq~ thing working too.
look at [rate~] for doing meaningful divisions of a sync-ramp.
Yeah I looked at that and read about it but I tend to comprehend what I see more than what I read so I havent made it work yet. So far the only way I learn anything is read about it first and then keep opening other peoples devices to see what they did. Its silly but sometimes I open half a dozen devices just looking for one object in action.
Wetterberg: It only took me an hour and a half to get your uzi, zlgroup to multislider thing to work. The moral of the story here is that google and youtube are a terrible place to learn this stuff and I should have opened the included tutorials a lot earlier :) it's a really rockin method too.