Monomod Client Dummy Plugin
Here is a quick and dirty patch to prevent Live from bogging and sends from breaking while you are designing a Monomod patch. I haven’t used it yet, but the theory is sound 😉 Let me know how it works…I’ve always done it the hard way, but I think next time I will give this a try.
http://dl.dropbox.com/u/6044993/client_dummy.amxd
nice. works so far.
is it possible to recieve the timing buttons and use for some other things?
"Yep. I just ammended the dummy patch and added an extra send."
do you mean you updated the dummy_device in the dropbox?
one thing would be really usefull:
to make monomod use lp user1 for testing purposes.
if it's really easy you can tell me where i have to look in the monomod patch (i thought it was in the js)
greets
forget the question ,yes, you updated the dummy.:)
i think you mean
(0) = button 1 with button 4 off.
(2) = button 2 with button 4 off.
(4) = button 3 with button 4 off.
(1) = button 1 with button 4 on.
(3) = button 2 with button 4 on.
(5) = button 3 with button 4 on.
this is translatable to 0-3 ?
if yes, nice quest.
Yep. I just ammended the dummy patch and added an extra send. Use an object named [r dummy_mnmtm].
Be aware, however, that the portion of the engine that figures out the triplet value is embedded in Monomod itself, and so your are going to get a value between 0 and 5, corresponding to this:
(0) = button 1 with button 4 on.
(1) = button 1 with button 4 on.
(2) = button 2 with button 4 on.
(3) = button 2 with button 4 on.
(4) = button 3 with button 4 on.
(5) = button 3 with button 4 on.
You will have to get creative in how to translate this if you want to use all 4 buttons in the normal manner (I know, beleive me: I had to get creative to make it that way to begin with).
I'll put the send in monomods for the next inclusion in the patches, and hopefully I'll have time over the next two or three days to get monomods abstract published.
Cheers
edit::
yep, that's what I meant lol…I don't even know how that got posted.
sorry me again can't edit comments.
what is with the lights of the key and timing buttons. some way to override the standard toggle behaviour of the leds? it's in the host, right?
thanks for answering
Yeppers. All of the lighting/toggling is handled by the Monomod host. I can add a function that will defeat that in future versions, as I have use for it in certain patches myself, but it will be a little bit.
The reason its like this is because there used to be a centralized timing engine in the host itself, and I had to change this a few versions back. When you started asking me about this stuff, I realized its really not necessary anymore, so I can rip it out and make that behaviour exclusive to the monomods abstract in each plugin. Kudos for making me think outside of my little box(es).
User1 thing will be solved later tonight when I get home. Its not a big deal to change it, but it has to be done inside the host itself, and there is some stuff in the javascript that I need to code to make it happen.
And I can't edit now, either. Wierd…I think it did that when I moved the comments to the popup window. Obviously a good idea is sometimes just that: a good idea.
Ahhh…apparently you can't edit comments on Blogger. Only posts. Freakin lame 🙁
Ohh, and by the way, here is a way to get individual values from the timing buttons. I don't know why, but my original post got all messed up when I left it sitting idle for a little while.
This won't do anything about the lights (you'll have to wait for that), but you can use this:
http://dl.dropbox.com/u/6044993/mnmtm_buttons.amxd
i was creative enough this night and just wanted to present you my translater i realized with a coll and some expressions. this is funny, now i take a look at your approach…
hmm different i don't even understand it fully.
probably million ways to do it in max.
i like this kind of problems and how you can find a way experimentally with max's objects.
thanks for your upload anyway
and looking forward for the other things.
Lol same here….I love looking at others' solutions to the same problems I'm presented with. I'm definitely interested in looking at what you came up with.
Its kind of like a crossword puzzle or something for me. I spent about 15 minutes on that solution when I was at work today. I wansn't even sure the results were possible at first glance.
Check up later tonight or tomorrow. I've been thinking a lot about the abstraction stuff today and have come up with some ideas on how to finish them, and some different ways to make everything a little more modular. I'm going to start rewriting the bulk of monomod in js so that its more easily editable, but in the meantime I'll post a revised Monomod_LPD that utilizes user1 instead of user2.
Cheers.
Well, as it turns out, there isn't an easy way to do the user1 thing. The Python script turns off the output of the launchpad when in user1 mode. I remember trying to work around this a long time ago, and just forgot about it. I just spent an hour messing with it, and have a copy that would work (if it worked hehe).
Actually, it wouldn't work anyway unless the standalone had a switch installed in it to ignore the grid output when user1 was selected.
Soooo…back to square one. Which patches are you using? Chances are they wouldn't be too hard to port over to Monomod format.
no matter. it would be only for testing. i have my own setup at user1 anyway. i already ported my first patch, with the help of your dummy device. now i will see if i can make use of the extra buttons.
if you still want to take a look:
http://dl.dropbox.com/u/2174210/mnmtm.amxd
Cool 🙂 The button lighting thing may get taken care of sooner than I thought. After rewriting Knobs last night, I realized that instead of making everything centralized, it would be betterI to make all the patches smaller, and self-sufficient, but still capable of talking to each other through a central communication system. So I'll be ripping the timing and mode system out of the Host patches, and just having them send keypresses, and reporting what the plugs send. This has been a conflict with Plinko for a while anyway.
Cheers 🙂 Love to have a look at what you ported when you get finished.
PS yeah, that's probably how I would've done it six months ago. Looking at your patch just made me realize how often I write patches based on how they will look when I am done with them lol. How completely OCD of me.
had several crashes now, maybe it's not a good idea to add some more clients if the dummy and the test device are opened.
yeah sounds good, better in every case. there are patches that will don't need any timing (e.g. your monotes)
i noticed i'm getting only sound out of boingg if the duration is set to 1. with the standard 1/4 i'm only getting random clicks with any synth but the metering shows midi out.(and it's not the attack dialed in 🙂
that reminded me of a feeling i had when testing monotes: very short pad-presses were ignored by any vsti maybe this is again my overwhelmed system.
but i have normally a good low latency midi response when playing vsti.
that means the host and monotes are causing feelable errors and latency or lag while midi processing ON MY SYSTEM
i'm curious if you get the same thing with boingg
I've found that its not a very good idea, in general, to have too much going on when I have the editor open (or have had it open and closed it even). I generally try to stay out of preview mode completely. This is a major gripe of mine…I've wasted soooo much time in m4l due to constant crashing. Save often.
Also, there are a lot of timing incongruities that occur when the editor has been opened in a session. Even after closing it, they still exist until I restart live. YMMV.
This might be the reason boinngg is acting up for you. I'll check it when I get home and see what it does on my live rig. The durations are tied to a makenote, I think, with transport-tied durations. But I could be wrong. I jacked with some of that patch the last time I ammended it in order to change the pattrs and whatnot, so I may have schmegged something. I was using it the other day with no problems, but with wacky Virus patches, so there wasn't much definition.
BTW that stuff you linked me about the Scale System…way cool. I'm definitely going to incorporate.
Ok, so I had a look at both monotes and boingg. Duration and performance is completely stable for me…this may be an issue with your setup. I'm not running anything on a PC, but I do have a Dual PPC 2.5 MacPro that I haven't tested stuff out on yet. Maybe this will reveal some problems that my two DualCore 2.1 MacBooks don't. Let me know if you come up with anything yourself.
Oh, and also: try running a set with this stuff (if you haven't already) without ever opening the m4l editor and see if you get the same issues.
One more thing: are you using Nomeout? Or just using the MIDI outs of each plugin?
yeah, i also noticed things are getting messed up if max editor was used. i'll try a clean session.
have not used nomeout yet, do you think it's giving me a performance improvement?
the patch i'm on is quit complex (at least for me) but i'm slowly progressing..
more questions:
what can i do when the patch is using the clear(matrix) message for all leds on the monome.
and another thing btw
how did you realize multicolor in some of your devices?
friendly greetings
Nomeout will give you a performance DECREASE because it utilizes interpatch send/return. I thought perhaps that was the issue. It gives you a lot more routing possibilities, though, especially with Plinko and Monotes.
Sending the (clear) command to —out should also clear the LPD @ Monomod.
As far as multicolor: that's tricky. Every one was different. There is still a lot of work to be done on different ports. The biggest thing is figuring out exactly what multicolor is best used for in each patch. TR256 was obvious: velocity. Again, everything is going to a matrixctrl at some point, so its easy to use colors just by adding to the z dimension of the matrixctrl. But actually implementing it was a bit trickier. As much as I've worked on that patch, I always wonder if it would have been easier to write it from scratch than port it from Stretta (and I actually started doing this six months ago, so that everything could be clip-based instead of coll based – it just wasn't viable to do the things I do in TR256 with the present state of the m4l API hooks).
Polygome was a little easier I think.
I didn't do anything with cafe or boingg, just because I couldn't think of a real need for multicolor. If anyone has requests, it probably wouldn't be hard to implement in either of them. I just couldn't figure out a way it would actually be useful.
The devices I write from scratch are always multicolor first, so to speak. Its kind of a hindrance in some ways: I started doing all of this on a hacked beta'd Win7Rc tablet with a NTRIG touchscreen, using Mathieu Chamagnes MMF. I had as many colors at my disposal as I wanted, and I was all about using them. Thus Plinko, my favorite and most used patch, doesn't translate to anything well except for the Launchpad (due to lack of colors). Another patch I've written and not released, Life, uses 25 colors, and is just useless on anything without at least 8-10. I really thought that we'd have more available in the way of multitouch or grid controllers with RGB by now.
Heheh. That's probably completely impertinent to what you were actually trying to ask me.
If you send me your patches, I'm happy to have a look and make suggestions. I know how messy the composing process is, though. When people ask me for patches, it generally takes me more work to make it comprehensible than it did to write the patch in the first place. Still, offer stands.
Let me know if clear doesn't work, I can make it so it does. I'm going to start rewriting things with Monomod tonight, more modular, so I can encapsulate the entire controller side in a js script, and put all the timing, lighting etc on the client side.
Cheers
"Sending the (clear) command to —out should also clear the LPD @ Monomod."
i don't understand it. you mean "s dummy_out" will understand something like this "/clear" ? does not work. i can send 64 note offs, but is this the way?
"its easy to use colors just by adding to the z dimension of the matrixctrl"
and how do i transfer this z dimension, with a fourth number? although this is irrelevant until i manage the basic import tasks.
i did not expect so many difficulties when taking out the whole stretta_monome stuff.
i can see parts of the patch led messages coming through in other launchpad modes (e.g. mixer). i assumed the whole focus thing is managed by the host.?
sorry question after question. i already learned much from you. thanks for that.
i have just reread the lp_programmers_reference.
there is everything.
reset launchpad with 1 message possible,
rapid led update and more stuff.
i assume you were referring to this when building monomod lp host. and i assume there is a way to send it from the client. Can you enlighten me?
greets
You should be able to send "clear" without the "/"…use OSC-unroute.js for this. If you don't have it, you can get it at CNMAT.
A matrixctrl understands the "clear" command, and when you use it, it will zero out and send all its values as 0. If you look inside monomods, you will see that the fourth input is connected to a matrixctrl. That's how it's able to work.
The z dimension is the third number of the grid values sent and received from Monomod host. This, again, goes back to the matrixctrl. You can change the number of steps that matrixctrl uses, so that instead of just being 0 or 1, it is say 0 – 24. This is available inside the matrixctrl patcher inspector.
Yes, focus is managed (mostly) in the host, and there is a simple gate on the output of each client so that its not sending data when its not in focus. This gate is part of the monomods patch at the matrixctrl I mentioned earlier in this post.
Unfortunately, even though the LP Programmers manual gives a lot of good info, its not pertinent to Monomods necessarily because the LP is accessed through the API. Because of this we are not actually dealing with MIDI, but calls directly from and to the API. I used to used MIDI before m4l was released, but its kinda sloppy; it prevents you from being able to use other messages on input to the Monomods host (because it depends on the MIDI input) and it means you have all kinds of MIDI messages floating around your project getting misread by other channels with MIDI input ALL CHANNELS enabled. That's why I use the API instead.
Shouldn't be a problem, though: you can easily tranlate the /clear message to a clear message with the use of many different functions in Max, but the easiest is [js OSC-unroute.js].
http://cnmat.berkeley.edu/downloads
Lemme know if that works for you.
ahh, now i got it. don't know what i was thinking. thanks for making that clear with the matrixcontrol. clear is just a message to it and it works of course(thought i tryed it).
and z is just the third number, works up to 23.
it's actually not unfunny to go through the patch and rip off all the unnecessary stuff.
resuming…
do you think if i dream how i connect objects at night it was to much max the last days?
I love mutilating other peoples patches….its a good pastime.
And I'd say if your dreaming max, that's just about the right amount 🙂
one thing that came into my mind:
if i want functions that are on pads in the original patch on the key and timing buttons, i'll need on and off signals.
e.g. a fuction is triggered if the key is hold down longer
For the moment, see if you can get by with toggle (one press on, next off). Next revision: the output from host will act the same way as the other buttons (0 for off, 1 for on).
Working on the scheme now, it will probably take a little while though. I have a lot of testing and thinking to do.
maybe you can even give them the same color feature, then with all the things you plan to do, it will be the ultimate app to launchpad bridge. (or at least a stable open base to work from)
btw: if some sentences from my side are strange or have bad gramar, it's because of the langual barrier. forgive me that.
and take your time, Soon ripe, soon rotten. Haste makes waste. Rome wasn't built in a day.
and cheers
Yeppers…they will have the same color capabilities, at least for the launchpad. It is my goal to make things that others can use;)
I think the key here (as always) is making small blocks of things that can be easily added/deleted without affecting other things in the patches.
Your english is very good. I hardly notice…if my ability to speak Max was as good as yours at English, we'd be in much better shape lol!
I'm anxious to get this portion done. I'm excited, I've finally figured out how to make a client/host relationship that will provide a way to use multiple hosts and clients and have them all talk together without needing one central patch to distribute everything. I'm learning some rudimentary Maxobj stuff in js right now (which is easier than I thought it would be)…optimistically I may have something to publish this week sometime.
So much for summer hehe.
i was thinking about your comment about the api calls to live. isn't it midi at the end of the line that live is sending out to the launchpad?
i'm wondering why there is this performance difference with nonome.
it is pure max and in max for live a patch can't send simply out to a midiport, it always runs through to live engine, is that maybe the point.
and the api calls + live sending out seem to be slower then udp communication and then midi out.
because i tested simply the sequencer patch i'm on in it's pure form with nomone and then my current state of import with mmod at 500 bpm
it's coming to the point were it's to much ledoutput, then i stopped the sequence and watched how long the playhead keeps on moving (some kind of buffered midi out is then going on.same with midi out patches notes are buffered) and it happens pretty fast with mmod. just not expectet.(have to say it's still running in dummy mode but without edit window,is that still performance decreasing?)
i'm already watching out for a better system. but not a macbook.:)
in this patch the playhead (moving led playing position bar) is very messy/buggy.
the maker nick himself says he couldn't get it to work properly.
it's going out of sync and is simply not restarting with live.
its simply a metro 16n @quantize 16n i think thats really going out of sync if cpu is stressed, gonna try your clock from the host, but it's at the end a metro too, i guess
maybe you can take a look at it someday.
i wanna achieve that now the canceled out control row is gonna be another note lane
and i'm waiting until fuction button on/off for advanced menu and then you may take a look. would be nice. till later..
Yes…Live is sending MIDI in the end. But some of the special methods available for communicating with the Launchpad (like fast-send) aren't available to me because I'm using the API to communicate with the Launchpad.
Nonome (I think…I haven't taken it apart or even dl'd it) works in max (not m4l) so it communicates via MIDI directly to the Launchpad (a little bit faster), and doesn't need to use send/recieve to communicate to the monome patch you are using it with.
Send/receive in Live really slows things down. Combine this with the fact that you are using the API to communicate, and there is your performance decrease. Unfortunately, this is the price of going modular, and of staying completely within M4l. The benefits are worth it for me, though (the timing is much tighter than before when I was using rewire to sync, and saving/recalling states is indispensible).
Yeah, 500bpm is high. I never test anything above 300, to be honest. I know precisely what you are talking about with Live getting behind when too much data happens. I have gone to great lengths to make sure that Live doesn't have to send anything across a send/recieve, or to the API(and the Launchpad) unless it needs to. This is (I think) one of the advantages of my patches. If your subpatch tells Monomod to clear the whole grid, instead of sending out 0's for the entire grid, Monomod knows that it only needs to send out the squares that are actually lit. In fact, the client patch knows this (its part of monomods abstract) as well, so it doesn't even send the extra data over the interpatch send to the host. This cuts down on the amount of communication necessary, and has increased the performance of my patches A LOT. It also helps a great deal with iPad/iPhone implementation (if you think the Launchpad is slow, try doing all this over Wifi hehe).
Yeah, my timing engine is pretty solid. If you tear apart TR256, it will show you some ways to implement restart/restart on timing change as well. Also, there is the one inside the Step Sequencer, which works well.
Send me a copy of what you have, I'm happy to take a look at it.
I'm making good progress on the new stuff. I've got a host and client working, both capable of running multiple instances, autoregistering and unregistering. We'll be ab le to run 24 clients (I think that is enough) and 4 hosts, each host with its own linked clients, with assignable ordering. The only thing I'm having problems with (as always) is figuring out the best way to save/restore settings between presets/sessions.
If you really need to run @ 500 bpm, you will probably have to use a slower metronome for Launchpads update. I've done this before with Plinko, and it works. It just means that you won't see everything that happens on the Launchpad, but it will be current with timing.