Just curious if anyone else has the problem when they rewire mlr to
Live. Whenever I control effects or hit buttons on the 40h the tempo
gets all weird sometimes. It's really annoying. This doesn't happen at
all when I'm just using mlr.

Anyone know what's up?

1) do you have MLR midi clock source set to a MIDI channel that is set 
to "sync" in Live?

2) do you have the Max Scheduler set to overdrive? If not, set it to 
yes. (in DSP options).  i've found that putting Max in overdrive greatly 
improves syncing.

3) make sure that there isn't a weird MIDI map between your tempo clock 
in live and some function in MLR, i've done it before and it feels like 
the 40h is playing itself...

1) yes
2) yes
3) not sure...

It did this exact same thing, but it was even more erratic when I used 
my novation remotezer0sl as the beat clock master.

Yeah man, the tempo is just super erratic...it'll slow down and then 
speed up etc. Really annoying...something is up with rewire i think.

zfigz, question for you; other than encountering your erratic tempo 
issues how has rewiring mlr into live been working out for you? I've yet 
to try it. Any other hiccups?

well that's been the only problem...it's good besides that, but then 
again you can't look very professional when your shit is unsync half the 
time.

I'm gonna just stick with using mlr as is and leave Live to the 
production side of things.

maybe it's because I have the max of 200 samples loaded into mlr...

argh, yeah...I can't seem to get the tempo to hold still for a 
second...it's constantly shifting down or up...very annoying...so yeah, 
no rewiring into Live it looks like for me.

unless you can show me what's up with this fidgety tempo...

mine's unstable but after minutes, not seconds.  it'll speed up then 
slow down.  ultimately I decided to unsync them, set mlr to a small 
quantize level, hit the metronome in Live, set both bpms to the same 
setting, get mlr going and then set its quantize setting to whatever I 
want.

from observing Live in master/slave mode with other computers, my mpc, 
synths and stuff Live's clock output is unstable.  I think mlr would 
benefit from sampling a lot of clock ticks before it changes, the 
current setup seems to be less than 5 measurements.  from playing with 
Live in master/slave mode I believe Live itself uses more like 8 clock 
measurements before it changes.  just a guess.

for me the bugger is that mlr rows lose connection with the 40h one at a 
time, after fast sample launching some rows become unusable, kinda 
killing the jam.  tehn is busy with other stuff, in time I trust he and 
the growing user base will sort things out.  mlr is an app well beyond 
my max/msp knowledge, props for getting it going in the first place, no 
doubt!!

we're all beta testers and a developers community, onward we go!

tonedeft - do the rows in mlr become unusable?  there's a thread on this 
(http://forum.monome.org/topic/1188#new) where i fixed this issue when 
it occurs, if that helps.

are you guys rewiring to Live just so that you have efx on the tracks or 
are you doing something else?

"are you guys rewiring to Live just so that you have efx on the tracks 
or
are you doing something else?"

- exactly. I've done it before and it worked fairly well earlier this 
summer, but I'm getting these annoying ass tempo hiccups that make it 
totally unusable. I'm think it may be because I have so many samples in 
this mlr set and that the computer is just freakin' out with all the 
buffering it has to do. I'll try again some more today...

I simply turn monomeserial on, open Live, open mlr, and then ensure my 
beat clock source is set to "to maxmsp" in mlr, enable sync for "to 
maxmsp" in Live, and finally I press play to start Live's sequencer. The 
tempo's latch...now when I pretty 40h buttons, or begin to tweak effects 
via my midi controller shit starts going haywire.

well i was curious because i've been working with a version of mlr with 
built in vst's  there's some limitations and it's fairly new so i've not 
worked all the bugs out.  but it basically accomplishes what you're 
trying to do, it seems.

and the bugs i've had are not with tempo, just related to the vst's and 
saving their midi controller cc's and whatnot.  anyway, i can share it 
if anyone's interested.

so you can put individual vsts on the groups? That'd be awesome man and 
exactly what I'm looking for. My mlr is already slightly edited, but I 
can just copy the edits to this new mlr. Could I have a gander ?

it would also save my cpu the trouble of processing Live's presence.

oh, and how do you set the tempo? (w/ the mouse?)

I'd like to assign tempo control to one of the knobs on my controller so 
I don't have to touch the computer at all. Originally I was doing this 
via Live with a knob assigned to tempo in Live, but obviously these 
tempo hiccups make using Live a tad pointless.

edit: doesn't the latest mlr allow for vsts?

you can sort of put individual vst's on the groups.  basically, what you 
can do is load four vst's.  they're routed in a chain: 1->2->3->4.  then 
you can choose which of the four tracks go to the chain.

the cool thing is that there's an extra page in mlr (that has some other 
controls on it as well) that allows you to toggle which of the four 
tracks are routed to the chain as well as which of the vst's in the 
chain are on.

yes, the latest mlr has vst support in it.  but it doesn't have a method 
for saving which vst's you want or which cc's you're using to control 
them.  so every time you load it you have to choose these vst's and 
assign cc's to them again.

i've debated on having a four-vst chain for each channel.  this would 
actually be pretty easy to do within what i currently have, i'm just not 
sure on how much cpu it would suck up if you ever enabled all sixteen of 
the vst's.  it is worth a shot, i just haven't gotten around to it yet.

either way, i'll clean it up a bit and post it within the next day or 
two.

also, tempo control...it could be assigned to a cc for sure but i don't 
have anything in there to currently do that.  it wouldn't be too hard 
tho.

Sweeet...yeah, sounds as though I should give up on the rewiring and 
just assign my ccs straight from mlr to my controllers.

I'll be awaiting your mlr patch...thanks again!

> there's a thread on this 
> (http://forum.monome.org/topic/1188#new) where i fixed this issue when 
> it occurs, if that helps.

EXCELLENT!!!  can't wait to try this later, thank you!!!

i havent really ripped apart mlr, but i think the problem is that the 
samplers are running off of an audio phasor osc, or perhaps the 
tempo-based version (sync~, is it?).  this of course makes perfect sense 
in Max, but is not great for syncing because it's all based on guessing 
the tempo.  what would probably make syncing better is a mix of 
tempo-guessing and clock following, where the phasor~ just counts 96th 
notes, and is added to a 96th note counter, to form a full audio 96th 
note clock, and this adjusted back to a 0..1 clock.  ive done this in 
reaktor and it works fine, although you end up having to make an object 
that decides how many bars a sample is (i stole mine from a factory 
reaktor ensemble).

just giving some ideas if anyone wants to try and fix this in an mlr 
hack.  i could be totally off-base on how mlr's clock works as well.

WOO HOO! I just updated Live to 6.0.10 and it works fine...I guess it 
was a bug in 0.09...

Edit: FALSE ALARM! I just tried with the mlr set I was having difficulty 
with. I think it's because there are so many samples. Hmm, I guess I'll 
have to make due without having any effects.

zfigz -

so i think reading about your problem jinxed me.  i had never 
experienced the tempo hiccup, even when re-wiring mlr (180 samples 
loaded) to Live (6 tracks, midi assigned effects, clips loaded) - until 
last night.  with my setup, the only hiccuped when i attempted to load a 
new preset in mlr, so it made it impossible to smoothly transition 
between presets.  it was rather annoying, but i couldn't help laughing 
about it because it made all of my transitions sound really chopped and 
screwed.

i'm going to spend some time looking into this...

rawray7,

keep me posted. I've got 200 samples loaded so I'm thinking that might 
be the culprit, but I don't know.

As for my Live set, I just have 3 tracks with effects on all the tracks 
and on 4 return tracks.

alright well here's the one i promised.  please lemme know if you have 
any issues with it.  i've used it live a couple of times with nothing 
major occurring.  but things happen...

full list of mods:
- keystrokes mapped to q-u for double-time, a-j for half-time and z-m
for reversing tracks 1-7 (respectively)
- click output (impulse) goes to audio outputs 3/4 when toggled on
- all output goes to headphones (audio output 3/4) always
- option of loading up to four vst's in a chain 1->2->3->4.  cc's
may be assigned to these vst's and the cc and vst settings may be saved
- hitting mod buttons 6+7 in row 0 opens a mod page with the following 
options:
   a) row 0, columns 0-3 toggle mute for the four channels (as before)
   b) row 1, columns 0-3 toggle routing of each of the four channels
      to the vst chain
   c) rows 2-5, column 4 toggle whether vst's 1-4 are on or off
   d) columns 0-3 in rows 2-5 toggle assignment of the accelerometer
      to the vst that resides on that row (see item c);  if toggled on,
      the accelerometer will control the vst cc which is numbered the
      same as the column number (example: toggling the second button in
      row 3 will assign the accelerometer to whatever the second 
assigned
      cc is for vst 2)
   e) rows 6 and 7, columns 0-3 are assigned to input buffers 1-8; 
hitting
      one will set up the selected buffer and fire it for recording
      (quantized, as before);  it will then set up the same numbered 
track
      for playback of that buffer number, change back to the default
      "remix" page, then playback the buffer as soon as its done 
recording
      (quantized);  this option makes it a lot easier to record and
      playback loops on the fly
   f) column 5, rows 1-7 are assigned to half-timing tracks 1-7 while
      column 6, rows 1-7 are assigned to double-timing them;  when
      the timing is less than 1 the led in column 5 is lit, if its
      greater than 1 the led in column 6 is lit, otherwise neither
      is lit (i.e. during normal playback)
   g) column 7, rows 1-7 are assigned to reversing tracks 1-7

known issues:
- if a track's timing is almost, but not exactly equal to one (say 
1.000001), then the led in column 6 (indicating greater than one) will 
be lit
- occasional issues saving/recalling vst cc's;  especially if you choose 
"write settings" and then immediately after choose "read settings"
- a couple error mesgs to the max window that i haven't tracked down yet

jmelnyk, thanks for the customized mlr patch...mine just had some 
keystrokes and notes binded...woo hoo!

no worries.  hope you enjoy it.

like i said, please let me know of any issues.  i've got another show 
with it in a couple weeks and the more people torture-testing it the 
better.

I'm going to try this after dinner, is this version kid tested and 
mother approved to be put up in the 'resources' section of the site?

thanks again for updating, great community!!

it's kid tested and *kid* approved!  so far, at least.  i know at least 
a couple people downloaded it and i've not heard of any issues yet (nor 
have i encountered any since).

so at some point it should prolly go in the resources section, yes.  i 
should prolly clean it up a bit and give it a different version number 
or something i guess (the one it has was just for me to differentiate 
versions i had, really).  i'm sort of torn tho.  it isn't a new app 
entirely; it's just added controls to brians latest patch, mainly.  so i 
guess i'm just not sure how to "file" it or whatever.

cool.

software revision control is something I'm concerned about with the 
monome applications.  in any software development cycle rev control is 
essential to developing a quality end product.

there's a lot going on right now with monome stuff, I'm very grateful 
and impressed at the stuff that's been produced.  once the waters settle 
a bit this is an issue that can be addressed.

open source software development is trickier to coordinate, in time it 
will work out.

argh

error:_mlr.mxb: can't open, bad header

no idea what that means. :(

re-download the file. it also might need to be re-archived. we had a 
problem with cross-platform archiving way back.

great work joe! your version is definitely a big improvement, and your 
video is absolutely testament.

i'm taking down the wiki soon, an instead i'll be managing all of the 
content from the main site, filling in the holes in documentation. i'm 
about to switch forum software, whereupon we'll figure out a convention 
for maintaining project posts and discussions.

source control with max patches is somewhat annoying, unfortunately.