One session view track to copy another
Hi, this is my first post on these board so I apologise if I’m putting this in the wrong area or other such novice behaviour.
I’m working on a live idea where when triggering clips in my live set, I can sweep between alternate versions with an encoder. To illustrate the basic principle say you have a track group, you have two tracks inside and you’ve mapped your encoder to turn the two tracks up and down with inverse values. You hit play on the track group and one they both play, move your encoder from one side to the other and one fades out as the other fades up. If you hit an empty stop clip on the group they both stop.
That’s essentially exactly what I want except for the annoying caveat that group tracks don’t show any kind of name, making navigating what I’m launching sort of impossible. So I started trying to get creative with some MIDI routing to instead have a track of dummy clips fire off the group track, which is hidden off to the side. It’s a pretty limited approach, you can’t deal with stopping by selecting an empty clip slot on your dummy clip track.
So what I was wondering is perhaps there would be a way with Max to create a device that essentially linked two tracks. Have a one track "linked" to another, so that when the first is playing a clip, the second plays the clip in that scene. When the first stops with an empty clip slot, the second stops with the parallel empty clip slot. Essentially I’d be using max to build the exact functionality of group tracks as far as playing and stopping goes (not so much the summing of audio), just I’d be able to give names to the clips on the primary controlling track.
Now I’ve worked with things like Bomes MIDI translator and ClyphX, but sadly have little to no max experience. So I just wanted to ask the community here if that sounds like something that’s actually possible with Max? Or are their limits to the way the whole thing comes together that would make that probably impossible?
I’m not going to be so taxing as to ask someone to explain to me how to actually build such a device. But assuming it is possible, if anyone has any starting points or links to good tutorials or such for a newbie they’d like to show me I’d be greatly appreciated.
Excuse the ramble, these things are always so convoluted to try to put into words. Thanks heaps for anyones help.
Ok so I’ve gotten this far, but there’s some fundamental here that I’m apparently missing. I’ve managed to find a number representing the clip just fired in the given track. I’m then using that to format a path message (which I’m arbitrarily point at track 2 for the time being). So far so good, but the part I don’t understand is why the live.path doesn’t seem to update where it’s focused unless I manually click on this generated message box. Even though this message box is updating, nothing I seem to do to try to get it to automatically trigger and pass this path on seems to work. When I click on it though, it absolutely does. With the newly focused clip I can click on call fire (another thing obviously needing automation but one step at a time) and it behaves appropriately.
Can someone explain to me why this path isn’t being passed on to live.path? I’ve tried layering in "t b l" objects everywhere!
You still need "t b l" before the last message box containing the path.
Hi Broc thanks for offering your advice. Is it something like this that I’m guessing you mean? This is how I understood the logic too and what I assumed should work. Although it doesn’t seem to. In this instance, fire is never called. Or at least, I can never observe it doing anything in live. You can see I snapped this screenshot as a clip was flashing (in a "trigger" status) so the relevant pieces are seemingly filling out variables and so on but simply nothing is happening. Can anyone tell me what I’m missing? (by the way I assume there might be a more elegant way to discuss this than me posting screenshots on these forums? Forgive me I’m new to it all).
Do you get any error messages?
(to see them right-click on the device title bar and choose ‘Open Max Window’).
For posting patches, read this
Ok so a bit of an update, I seem to have discovered a limitation of live.observer I wasn’t aware of. It seems able to output some sort of value that it’s observing (i.e. which clip slots are being triggered), but it doesn’t also output a bang/trigger that in turn can do something with that information. See the attached screenshot (and the error message at the bottom is what I only just realised with the previous configuration that was seemingly my problem).
Yes, here is a quote from the documentation ‘Live API Overview’.
"Note: changes to a Live Set and its contents are not possible from a notification. The error message in the Max Window is ‘Changes cannot be triggered by notifications’. In many cases putting a deferlow between the notification outlet and the actual change helps to resolve the issue."
Ah that’s the information I was looking for, thanks so much. I seemingly missed the part about deferlow as a solution when I was looking through help files. Fantastic! I now have a really simplistic working version of this plugin;
----------begin_max5_patcher---------- 1379.3oc0Zs1aaaCE8yN+JHDBvZARMDod5gsAjf1OLLzMf0BLLTLXHKwXyEY RAQ57nE8+93CoDmDKYlDYpr9gHXZJpiN7dO2Cute6nIdKXWi4dfeD7EvjIe6 nISzCoFXRymm3sN657xLtdZdT7UrE+q2IluRfuVnGV.V.JaGktYMainDKz2B pYzyYTAMaMVO+SqIYkfyXkEs2j4ND2TgMvwaQFco2I.OOv+zLkpLQ9JBc47Z btvLqPT5T+SjWhUWfogSiTWl5e6MQJzOPIneGLwaKrvIeU+nf9xa8VfSns3F pF66Gcj5Om7xXmB7435R1U6lffOSBxJhIJPcIBYnmcyKoGZZImsdMlJdDu7w Se+G.m82fy9vue5m+q+3O+soKHec2jjucjzNXh3jYpWdDTSAQ9OhIppwbI5x DDFc68isibhdRTzNV3s.DJRAg3GAmAjX+jfIe1fKyJ2fAbbEtNSfKuAjQK.0 XBsZifCHB.iBJYYEf2P.BIscwzoSea6hURn3b1FpdEiF3METp9EOHTuqjn+a bXGosvCc74ZLmmsD+HZD4vDVTRhlQLwoMwEwcvHgOEFAMbBYpfEit7PxK5Ur WtIUqegjx6JtIpOwLHZjD4wWWUCNl.AuC5vvlfDM0D3aDU76iZBFq7HmRHoA FkkDKxihOz4QcIPKGCWCD0Y4W.902CjOmEpOy.4RfTyJG5hfA9ZYETCej77p BNKbHKCZp.j9H.8bRI072v5+jn11rPbpICDkDrU.2SlYQCIyBuSK3EZvnCst JYbq6MyFz3SHnW8+fYiUR8Oc2+FbSrAMtCPc4h8dk.CGKG8RWjbogS7ZtRLi KXUFSnbvRl7MR5xrlsY4JvUqH4q.xkDTvvb5OH.kjKvSAeRdqx4IspxnxaRr JSHmg56yxEaxJUdXK0RmqvfpxraTKJWlArgCXmCxZjTeCYpbwD0jkKw0porV 5G1.m7RREW97wT.koL8tj2tP615a5.uUl3aNORyYxLNfm00VILcjryLxmnOx DvumCzCCFI1gbtxp2u7y9p.Qp11GtjiAx2YzvRZ6kvh7MERQFYQCu0Ii4GNV l.WxjJBkjKwy4XgIOkCf57w47Rl7.ogiP+QLMG.lF0mOw.zHcdqwJIrIlBEo ClBS6KILdzNVQtrd.3bRM18wMQFSHgw8E1DFMVGSWlkMU9EJT6dpYltvVZum RG8zLo0LHO6RbwbyK17Lgr99hMBS+qmbKCMwadEtlS3BLMGeaLmgZGRBVRAq 1M8F7Rz5ss.ou4BrWZ1+UkZ+w2St+XzHn262vWvd6Kf+gNwsKZyo8NpUkeVv 9aURX3XQIU0LY9r3FsRegN1YNgVfu18LEL0XtJn2nmC+APec5V.Z9slfw85Y OXr9Q3ZJJxw0WNzsJxZ+TPS7Sbu0FCh++esQUe.JvWRxwCaEx13wllyotXAu GpcjzZ0uCVOZTKUpHr4FFCjmQYThzc67pr5s5xh6D5ZJOlD1mNGBNl1aGI2W sZcP+869BN64FRoWMcandv+4LzHRM98YMNaScd66QqFB3NPUf4BB81NP+k6N 41VSZEon.S2t4VqIEULYNVCH5nCxViIKfj5WjA.cFjz8ceufxszDzlsNcWtc IndvyqCT46VPoZlkkTk6hohsINOLzoLkFSPavj63IU2Q1KOgbaXtpj19CnbK lBrhmftMyyF0.kSeWxSIVDiG315KOfB5.SNNdxp8tX2hIaJCiba0kPqJt36V g7GvAc.Jnicr.spjWzH.JnM0Wfu1brD6Xwbax9ft0c.zJh5AH+fCJqIJWZB1 FL41RwPqJEiba.kMkhScJMkZSg3WRDt7Ce+n+Cz6Tq1G -----------end_max5_patcher-----------
There’s some limitations, like follow actions sort of screw the whole thing up (and the live API doesn’t seem to give hooks into follow actions at all). Also it’s really only based on triggering clips provided there are clips in the controlling track. I.e. triggering blank slots in the controlling track that have clips in the receiving track doesn’t always work, but that’s not at all what I need it for so I’m ok with that. Stopping clips in the controlling track with blank clip slots totally works across to the receiving track.
One thing I’d like to put together just to make it a little more sophisticated would be to select the track by a drop down (right now it’s a numbox for the track number, not something you would always know). However looking at the paste for "Live API Choosers > Browse Tracks" it seems to output an ID no. rather than the track no. I’m not sure how to get from an ID no. to its child "clip slot $1" (whereby you pass in the variable at will).
Thanks again for your help man. I feel pretty pleased for someone making his first patch!
Broc, I’m curious about something in this patch. Are the TBL’s necassary after the Observer? Can’t the Observer output go straight into the message then into the live.path?
The message box triggered with ‘t b l’ after the observer is required only for testing, ie. viewing the output. To see the value and pass it through you need to send it to the right inlet and then bang the left inlet.
Yeah I’ve been doing that sort of thing just for my own brain rather than the max patch itself. Helps me keep across whats happening when testing. Can anyone shed some light for me on my questions above? About how with a "id #" for a track I can navigate to it’s child clip slot. As presently I only understand how to do this referencing the track by it’s number (as in "live_set tracks 1"). Thanks
You need to assign the track id to a live.object and send it a ‘getpath’ message. This will give you the track path where you can append ‘clip_slots x’ to get the path of slot x.
ah awesome thanks so much. Max is extremely well documented and the way that you can copy examples right out of the help files is fantastic. However the thing I’m finding as a newcomer at the moment is that I know somethings possible but I just don’t know what words to use to search Max’s help or even google. So thanks for filling in these little blanks for me I really appreciate it.
To that end, I’ve been expanding my basic clip launcher to something more elaborate I wanted to use it for. To skip over the details basically I’m moving between two sounds, but every time a new clip (and I check against the last launched number and such) is launched I always swap it back to the one on the first track as soon as the clip plays. This essentially works, but as might be expected there’s a couple of milliseconds of delay. Because max has to take the "clip just fired" message and then perform the action (which is moving a macro rack).
Could someone head me on the path to making this action perform a fraction before the clip play? Or a general idea on how to try and remove this delay between the clip play and the action? Or is that something hugely advanced and not entirely possible?
I think the latency problem can be handled with quantization assuming that quantized clip launching is used. Basically the same quantization could be implemented for the target action. So the clip launch (blinking) would just notify the action to start at the next quantization point, in perfect sync with the clip start. Since the quantization points are known, the action could also be started a bit earlier to compensate for possible latency of performing the action.
Yeah quantization is definitely being used. Is there max hooks to get at quantization specifically? I tried implementing a faux quantization with a metro object set to bang ever bar (same as my global quant). It worked the same as waiting for the clip fire really, still a couple of milliseconds behind.
(by the first sentence in the post above I meant that I’m using global quantization in the project, set to one bar)
Unless there’s an object or something I haven’t come across things are looking a little grim. If I’m understanding this thread correctly, perfect quantization with live for programmatic tasks is near impossible;
Is there any other object that initiates quantized actions other than metro?
Hmmm so I’m discovering. I imagine in a wider variety of applications this would probably be a deal breaker for the idea. I might be able to get by with the small quirk for what I’m doing though (this is all a part of building a custom live performance set). I’ve set up a sub patch that outputs a bang a 32nd before the end of every bar, a really shoddy way to attempt to compensate a little for the delay in messaging. Seems to work alright, but certainly not millisecond perfect;
If anyone’s curious, this is the sub-patch;
----------begin_max5_patcher---------- 597.3oc0VE0aaBCD9Y3Wgk0djUgsgPRkpz1uiopIf3R7DXmAlsrU0+6CNCsI UAG.kgReH1wGGbeee24y9YWGbh5.uBitG8MjiyytNNfoVCNcqcvEwGRyiq.2 vR9uUI+.6YdjlePCl0nDTRuUUsNmq0+YO27kwIwxLrW2L5wN21GqS2IjYeuj mpMdRWyty2Cw5lBZGo924+56H1BgqABelD1GumTRsLt.hF9qkh379mHqKDxF r.Xmbj6Uh+BtSnMg3UeM.Gbl1Z7EW21AuQpMZUVVNePUPH01Ie.vWFk1SaKj 22JEOkKjYvkAxyYw5gInc1sgXxoaZmVQswtolYoSIyNG0.B0L4sIqRWGASg8 imMqdV1M.M5rlpJJ3RS1AOCpY9jXaINnRL3Mnag.ASnrz+JwfAJU2W1rgCYZ 8LH4XQl8bAP1Yk8FNr+mMb7udLW7D5SBxCOvHH8NtDz.DOuhiZhGc3xXuKTJ y5ZHuYc6DIx5dXB8Vq87.pUAWWpPDI5K+rNVpahLrHNUK9UyesenlU4JB1qP LGlQ1XUtht0Z4YUsXzikKX0UPuLkWjvUFgZkM8J3lSupKR3kVO72a7h.cEbZ Yn0KAv9frCKUUK0WVa5+co6I0KQTnMTDylDM0lPgSQhBNRhffiyEx2ecZf.s 1OU2pT0ko8BP+0YQuwgs7JsPFqEJ4wN4ehS6Da2xkGeVZgX6dUi.1ABzimMK NILQtDlBVTLMJYJbYkI+QfoEFR2fESzQpRjECRiAQrEUjXiIuQWTHELBHsrH JZjHhMSD0r3E2+Q4X2Na -----------end_max5_patcher-----------
As you can see there’s an input to turn on and off the gate for output to. I only want to receive these bangs in certain conditions in my patch.
The counter can be avoided by using a single 1 bar metro and delaying its output by 1 bar minus x ("ahead time"). It may also be useful to set the ahead time in milliseconds, ie. independent from tempo.
----------begin_max5_patcher---------- 866.3ocyXEsbhBCE8Y7qHKy9n0g.hn6L6L6t+Fc53DfqZZgDWH5Z2N8eeCIf Uq.lBVl8EsbS3ly4bu4jXeYjkcH+.jai9F5djk0KirrTgJBXU9rkcJ4PTBIW MM6HdZJvD1i0iIfCBUbLJjjg9NBuv0AInQOkWMkUblHm9WnXZXmINkgY6Ror DPnRKtLHMVkLd3i24hOMALRpJA1+LiRRP+hmDWM7VhHZCksdYFDIzTwclqbc P3YKJ9Zwb0CxOQO71hy2IpVcmhfuNZTwGi6oNP1.jXo.jBHJCk1aUvoGpful 3NS+zTAF7GIJuPDDYDVdBQ.RA3lzLfm2CY.q3O1KPIC9WQFpVccHwyaAcZrs QOzAEJExyIqgKjnuh+3BiaMBSP+ElEpcISCzaYFJgogVmubmxBouxhW+kEs4 wT2t1uPktC2RkIFRHO2Wcws65BdgpCw0qX4Pdy5ptDRXq6lvjP2CSjqRwrJy 9dR1QVbxv2iev1TqErA8BN9mvY+F4r6wLkIAk.xVBLRXBz91mwH6UIbRQ2R4 bxI6g3kDgHiFtS.u8W4kpSo7Tv+jc.eUU3p3mBgcLpFc1kD8rQ4YwPlx9ulA igUMOX9V.hSnoJxMo1YHfs4M85T1dZNsTbpaBvgsbVwQrMleBiwEDAkyVdrI nNNpT.wyMuTox1L0x3FLo9woL06NodlPEx8OkcLG6MNaNU06Vd+K6UNWL2vy D00qWGiS4wWgRIb15124bQBaSCRnrmJRWik6hDviaQCVw00O8XJmgputQWJA EhBq0+z076g32r+YaVmyUmh3pcP8TdJtNW0Fodqyw8wBUvWuNAL1azoMR44q OOHnhNsRpA6bx0x6c9QJy0bLY+pxylZTU9FeeJEgpsv5TSg0f5pilM9Ue1AZ TNT0uU5396OH0zo13l1oW+RLddyMhbN2HFzPqpz6KiivLzO98NBSHaTUOPhD RCYDtmcwAcqKVqPy7z+1.2t1EeoGkJCxyZXu++3fBEEwOWAy46xhpRW0sWQu AjXHWPYpy+OYRx8tH7w4rgFGCrSKkoz3sbomSIFZXuloPJv.D8NX+YCIeSfj +fBohyQLpvMfPxDUxYXgz4stMfooCOl9eSmlaBl7FVL4YBlBFVLYr4zv4WhM Ze27dnSxGdcz+D4kesJ -----------end_max5_patcher-----------
Hi Broc, sorry a very late reply. I’ve been busy with other aspects of the project (amongst other things!). So I just had a play with your addition and it seems to work pretty well! I had been thinking about trying to incorporate some kind of delay compensation element, then I could map a controller and if I heard things sounding a little off, bump it up a notch.
However I was wondering if you could help me wrap my head around how it works though? Theoretically if I had a metro sending out a bang at the start of every bar, then ran it through a delay of 50ms wouldn’t that make the bang about 50ms late? If my issue is that the bang is already actually coming a touch late, surely I need to compensate in the other direction?
Now it would appear that your patch does absolutely that, I’m just trying to wrap my head around why. I thought I would have to undercut the bar (say going back to my method of about a 32nd before the bar) and then add the delay from there. But it seems you’ve got a sort of inverse delay?
Thanks for all of your help, I’m still really surprised that I managed to get this idea off the ground seeing as I knew nothing about max when I started.
With a very quick glance, I would say that if every bang is delayed, by 1920 – x ticks, apart from the first bang, it’s as if you applied a negative delay to the following bangs. The metro doesn’t deliver an absolute clock.