#23

Uhh… How frustrating. I guess Max 5 standalones won’t work with 10.10 and above then. I’m on 10.9 because everybody with a mac more than 2 years old says how slow 10.10 is.

I’d like to do an update to make it work on 10.10 sometime soon. There are zero features I want to add though, so it’s just a boring compatibility update for free software that I rarely use anymore myself (thus hard to be motivated). Downloading 7.0.3 now to see what’s changed.

#24

Particularly as I shelled out £1400 for a new 13" MacBook Pro today, for music purposes.

I understand your reluctance, but here’s an idea…

How about the ability to set up inner loops independently of the position of the play head, say by holding down a top row button, selecting the inner loop region, then when the track plays through that region it loops it until the end button is pressed, at which point it runs out to the end of the line. At the moment the behaviour I’m seeing is it jumps into an inner loop as soon as ones set up and exit has to be timed correctly in terms of a manual press. Or am I missing something…

#25

Well, if you get around to doing it, I will send you some nice beers. :stuck_out_tongue_winking_eye:

#26

You’re not missing anything - that’s the classical implementation of inner-loops from @tehn’s original mlr. I don’t have any issue with the ‘performative’ element of such a gesture, as mlrv has always been about focussing entirely on performance (rather than composition).

The idea you propose is certainly interesting and has appeared in a number of recent monome step-sequencers in various forms, but it won’t make it into the mlrv update. The code to handle button presses is already seriously overcomplicated and honestly unsuited to visual-code (would really need a text-based rewrite).

Of course the software is open-source, such that users with different needs to my own can manipulate it to their own needs.

//

I am now working on a simple compatibility update to get everything working effectively in Max 7 & 10.9 / 10.10 (maybe even Win8?). I will be building standalone applications where possible to avoid the bulky max project and have a higher likelihood of success for first-timers.

#27

windows 10 will be out in a couple months (almost used an emoji but resisted)

1 Like
#28

The last mlr style clip slicer I made I coded the press data processing in js. Easily took about a quarter of the time and is way more friendly to look at…

#29

Thanks Galapagoose, that’s much appreciated :blush:

#30

@stevieraysean I did this for the mlr sub-patch in monome_sum but find it runs into performance issues when you start pushing the CPU with audio stuff (as js is all low-priority in max).

That being, said I’ve done some minor updating to get things to work properly for me on Max 7 in 10.9: https://github.com/trentgill/mlrv2

This is not an official release, but download the zip and let me know if you have any feedback.

#31

@Galapagoose cool, i’m out of town at the moment. will have a look when I get back.

the mlr/mash sampler I made is a small part of a much bigger environment i’ve been working on so I haven’t exactly stress tested it yet… probably end up making it in mxj if thats the case. I’ve found that to be pretty good performance-wise…

I’ve hardly touched mlr in quite a while

#32

For completeness’ sake, to note that I have followed the method I described above in 12 steps, on my new MBP 13" running Yosemite 10.10.3 and have achieved a correct installation with fully working MLRV. Happy :O)

#33

More updates…

In Max 6 the preset management doesn’t appear to work, it’s ok with Max 5
In Yosemite the Rewire functionality doesn’t work
I’ve never found Max 5 particularly stable and it’s no exception under Yosemite, in particular, switching sound cards appears to permanently disconnect the grid, requiring running a test patch and/or Monome Sum to get it connected again.

Essentially, I would say that in my view unless there is development of MLR-V for OXS 10.10.x and Max 7 this implementation of the Monome on new Macs is becoming obsolete. I think people should be aware of the strife involved in trying to do this before committing. If you have an old Mac running a 2011 OS and Max 5 and you don’t want to rewire into anything later than Live 7 or 8, say, then possibly go for it, but otherwise I would give it a miss.

#34

haven’t used it in a while, but this was always the most stable/working serialosc version of mlrv in my experience. never had any rewire or driver problems that newer versions have in max6.

http://monome.org/community/discussion/13529/mlrv2.2-serialosc-edition-with-alphanerd-plugins/p1

#35

Hi there

A few questions…

What’s this supposed to look like? Is it standalone or do you need to open Max7 first? When I open it I just get a list of patches down the left and the delay window on the right, nothing else…

#36

First close the delay patcher.
You then need to load the “_mlrv.maxpat” file from the list of patchers (double-click). I had it auto-loading the delay patcher to avoid the long load time when working on things and often having to reload Max.

I need to do some heavier duty testing (of the file save/load system in particular) then I’ll build standalones for Mac10.10 & Windows 8.

Of course any feedback is appreciated. I’ve been successfully using it on a brand new mac on 10.10.3 and an older box on 10.9.4. Haven’t tested it on my micro Win8 computer yet.

#37

ok, Ill try that.

This is probably a stupid question but will the standalone be 64 bit, rewirable into Live 9 64 bit?

#38

Indeed it will be 64bit. I’ve spent some time removing the ‘xsample’ external requirement which was the cause of the 32bit restriction.

There’s definitely some things missing in the version mentioned above which I’m working to conquer today / tomorrow.

1 Like
#39

quick appreciation post, putting all this work into an essentially free tool

#40

Yes indeed, it’s a lot of work and not taken for granted.

#41

I’m on 10.9 because everybody with a mac more than 2 years old says how slow 10.10 is.

I read you're now on 10.10, but just in case it helps: i've been on 10.10... for awhile now, and I haven't found it to be slow(my laptop is 5-6 years old)... but i did find an issue which was a process(check in Activity Monitor) called 'powerd' which sometimes goes higher than normal(up to 4+% when it normally stays below 2%). When i looked it up online, i heard of 2 things: http://www.computerworld.com/article/2499803/malware-vulnerabilities/mac-os-x-trojan-steals-processing-power-to-produce-bitcoins.html crazy shit! but this seems more current, like a prob i had recently: https://discussions.apple.com/thread/6841939usg=AFQjCNGzW_oiXFyIqAX0s9gwhoatpbzxjA&bvm=bv.93112503,d.cGU https://discussions.apple.com/thread/6841939

and killing ‘powerd’(simply quitting(not even force-quitting) within activity monitor) always returns my comp to what seems like normal speed. i dunno… in case you notice this or others who said it was slow start to notice, just thought i’d share(it doesn’t happen often, seems to happen every now and then when returning comp from sleep, but when it does i particularly notice the graphics stuttering).

Monome Beginner Help
#42

Thanks for the links. I have a feeling it has a lot to do with using a HDD and not solid state. I’m surprised Apple still ships HDDs in their hardware at all…