Hidden multitrack recorder

[qbas]

Dear maxforlive friends,

I try to build stable and realiable AUDIO recording device (or set of devices) that will work on multiple tracks together in sync.
Idea is to have Ableton Live for playing (and composing), when my hidden multitrack will capture everything on multiple tracks -even when transport is stopeed.
Of course outputted audio files must be in sync each other, or can be one file witch multichannel inside.

If I put on each track separate maxforlive recorder device, then it works good, but each device start and stop in another time, so outputted files are not in sync.
If I put in one device sfrecord~ object that will capture 16 channels, and I will take audio from other tracks into this recorder via plugsend~ and plugreceive~ objects, then outputted audio file has 16 tracks, but I have no 100% sure that plugsend~/plugreceive~ will always works and will pass audio in sync from each tracks.
(because plugsend~and plugreceive~ is not proposed as good solution generally)


Please help me to find best way to build such maxforlive recording solution.
What idea can you propose for this?

Thanks in advance.
Qbas

[broc]

I believe there is a basic problem with your approach. Keep in mind that tracks may have different delays due to different plugins. This is handled in Live with automatic delay compensation such that the track outputs are globally in sync.

But if you record the individual tracks directly (starting at the same time), the recordings may not play in sync due to different delays. So you would need some delay compensated start of the recordings which I think is not feasible in practice.

[qbas]

OK. but what if I will put all recording devices (created in maxforlive) on separate tracks, and audio will be routed from "musical" tracks to this "recording" tracks? Then delay comensation will be applied I hope, also volume and mute.

[broc]

I'm not sure if that would work better.
It depends how delay compensation works internally, but I'd suspect it's applied just on the final mixing stage.

[qbas]

But I can disable delay compensation just for be able to hear what is really recorded by mentioned hidden multitrack. I use Live as virtual instrument for my groovebox, which is MASTER (in synchronization), and I accept playing with the same plugin/device chains on every track , just to be sure that introduced delay is always the same.

Then still question is how to make this hidden multitrack recorder reliable and in full synchro.
As I mention earlier now I experiment with plugsend~/plugreceive~ objects, but they are not proposed as good solution. Broc I'm really happy that you are trying to help, your voice about delay compensation was surprised me, but fortunately I can workaround this by disable this genuine function.

[broc]

I don't think that sending audio across m4l devices is a viable option as it's not officially supported.

So it comes down to the question how to start multiple recorders in perfect sync.

Here is a possible solution:
Each recorder contains a [metro 1n @quantize 1n @active 1] connected to [onebang] initially disabled. If it gets enabled the next bang from metro starts the recorder exactly on the next bar. For enabling the onebangs (to trigger recorder start) there would be a "master" m4l device in the master track with a button that sends a bang to each recorder. This can safely be done with send/receive since accurate timing is not needed. After the recorders are started Live may be stopped and recording continues, but can be stopped at any time with another message from the master device.

PS.
In theory metro+onebang could be replaced by [delay 1n @quantize 1n] but I'm not sure if that works reliably.

[qbas]

I don't think that sending audio across m4l devices is a viable option as it's not officially supported.

So it comes down to the question how to start multiple recorders in perfect sync.

I agree, and thanks for naming the problem.

Here is a possible solution:
Each recorder contains a [metro 1n @quantize 1n @active 1] connected to [onebang] initially disabled. If it gets enabled the next bang from metro starts the recorder exactly on the next bar. For enabling the onebangs (to trigger recorder start) there would be a "master" m4l device in the master track with a button that sends a bang to each recorder. This can safely be done with send/receive since accurate timing is not needed. After the recorders are started Live may be stopped and recording continues, but can be stopped at any time with another message from the master device.

PS.
In theory metro+onebang could be replaced by [delay 1n @quantize 1n] but I'm not sure if that works reliably.

Proposed option is very good and I really hoped for such smart sugestion/idea – thanks for sharing!
If will find nothing better then I will switch to this solution, but firstly I would like to ask for little different solution still based on your idea, where will be possible to start recording even when transport in Live is stopeed.

Instead of starting with „next bar”, can be used starting with „next second” , for example?
If yes, will be [cpuclock] object good as global clock across multiple m4l devices or this is bad direction?

Thanks!

[3dot...]

just a simple question... and feel free to correct me if I'm missing something..

can't this be done by mapping several 'looper' devices to some m4l 'central control unit'
I mean.. the tools for recording audio are already well built-in to live..

grabbing audio tracks from the regular routing scheme..
(input selectors..monitor off)
and launching clips in sync for recording can also be schemed..
(although 'clip launch quantize' unfortunately cannot be set using m4l..
the global q can be set temporarily instead)

I'm intrigued ...what exactly do you plan to do with this audio that's essential to use sfrecord~ instead of lives' recording tools ?

[broc]

@qbas

I understand that my solution isn't ideal as it requires running transport to start recording.
So basically you could also use [cpuclock] instead, quantized with div and mod operations.

It should be mentioned however that there is still a problem with both methods due to inaccuracy of send/receive for enabling the onebangs. In special case it may happen that some recorders receive the message just before the next quantized event and others just after it. This situation can be avoided with my method by looking at transport and press the record button somewhere in the middle of a bar.

But here is another solution, simple and safe: using transport start as record start. This can be done with [plugsync~] in each recorder. It sends the transport state (1/0) on the left outlet with precise timing. Immediately after start the transport may be stopped. Note that this method doesn't require any trigger messages from a "master" device.

@3dot

I think the goal is to record audio in Live while transport is not running.
This makes sense for example when playing Live as virtual instrument (a la mainstage).

[qbas]

just a simple question... and feel free to correct me if I'm missing something..

can't this be done by mapping several 'looper' devices to some m4l 'central control unit'
I mean.. the tools for recording audio are already well built-in to live..

grabbing audio tracks from the regular routing scheme..
(input selectors..monitor off)
and launching clips in sync for recording can also be schemed..
(although 'clip launch quantize' unfortunately cannot be set using m4l..
the global q can be set temporarily instead)

I'm intrigued ...what exactly do you plan to do with this audio that's essential to use sfrecord~ instead of lives' recording tools ?

Thanks for interesting in this subject.
I didn’t use earlier looper, so I don’t know how exactly it works, but I guess it can only capture short loops (8 bars or so), but I need record for example 3 hours of rehearsal.
Looper also is linked to transport in Live, but I need something not depended.
I use MC-808 as main sequencer which also use vsti and sampler from Live. Often I play intro on keyboard and during it I hit Start on groovebox. I would like to record all , even with intro – so recording in Live is not a solution. I need something simple like hit record and after 3 hours hit stop. That’s all. Recorded tracks should be in synchro for further editing/mixing.

I use Live as editor for MID files, editor for audio, host for vsti/vst, effector, hidden multitrack, and more. After trying with many many controllers I found that Live is good for me as additional tool, but as main instrument I need something simple that give me direct control under change songs (in MC-808 is easy to switch patterns on the fly), control over volumes and mute (motorized faders, buttons), switch programs on syntch etc.

After DIY controllers, MCU, BCF, BCR, Zero SL, TouchAble, TouchOSC, Lemur with MU
I still feel need to use hardware for main operations (change songs, and control volume and mute). I think additional controllers maybe I will use in future, but now I have more fun to use this old roland than looking on iPad with millimeters knobs, just too small, too many mappings, too complicate. I don’t need to be expert, I just like to record and play.
Of course it is valuable to know others possibilities.

Of course for many Live with controllers is best option, for me it was for 5 years, but now I goes to mix hardware/software.

[qbas]

@qbas

I understand that my solution isn't ideal as it requires running transport to start recording.
So basically you could also use [cpuclock] instead, quantized with div and mod operations.

It should be mentioned however that there is still a problem with both methods due to inaccuracy of send/receive for enabling the onebangs. In special case it may happen that some recorders receive the message just before the next quantized event and others just after it. This situation can be avoided with my method by looking at transport and press the record button somewhere in the middle of a bar.

I think about this yesterday and found that it can be omitted by not “start with next bar" but "start with second next bar" or even third next. The same can be with "start with third next second" – this will give enough time to prepare all recorders. Even three seconds is still OK.

But here is another solution, simple and safe: using transport start as record start. This can be done with [plugsync~] in each recorder. It sends the transport state (1/0) on the left outlet with precise timing. Immediately after start the transport may be stopped. Note that this method doesn't require any trigger messages from a "master" device.

Yes but this will eliminate possibility to record intro (that I play before starting playback of pre recorded sequences). I completely goes to hardware sequencer as master, and I use start / stop as part of music, so recorder must working alone all the time. Ideally would be to have RME interface with recording to USB, but I have no money for it now – so I decided to use m4l and SSD disk (for ensure performance even with lowest latency).

[broc]

@qbas

I understand that my solution isn't ideal as it requires running transport to start recording.
So basically you could also use [cpuclock] instead, quantized with div and mod operations.

It should be mentioned however that there is still a problem with both methods due to inaccuracy of send/receive for enabling the onebangs. In special case it may happen that some recorders receive the message just before the next quantized event and others just after it. This situation can be avoided with my method by looking at transport and press the record button somewhere in the middle of a bar.

I think about this yesterday and found that it can be omitted by not “start with next bar" but "start with second next bar" or even third next. The same can be with "start with third next second" – this will give enough time to prepare all recorders. Even three seconds is still OK.

I don't think it would help much. The problem is that send/receive messages may not arrive exactly at the same time on all recorders. So for example, if the message is sent just before a quantized bar/second interval it may happen that some recorders will receive it early enough but some do not. The occurence of this situation can be reduced by enlarging the interval, but not eliminated completely.

[qbas]

The problem is that send/receive messages may not arrive exactly at the same time on all recorders.

But I would not synchronize directly to message sent from master control recorder device, and received in each recorder.

Maye better to send from master control device message "start recording at time x" where x will be calculated by adding for example 3 seconds to actual time. This calculated value will arrive to each m4l recorders, of course in different time, but it will only inform them about detail time of start recording, and enabling mechanism of checking actal time. Now when specified time will arrive and then each will start recording.

The only problem is I dont know to make [cpuclock] will report (send bang) that specified time "x".
Should I use metro to check every nanosecond? It will be heavy for cpu as I think. Do you know better solution? thanks

[broc]

That's a very good idea!

I believe the highest possible rate of metro is 1 millisecond.

But instead of cpuclock+metro you could use [plugsync~] which sends a sample count on the 8th outlet, regardless of transport state.
I think this would allow sample accurate synchronization, ie. perfect for audio.

PS.
I've just checked that the sample count is sent out every 64 samples.
So it would make sense to calculate the start point "x" as multiple of 64.

[qbas]

Thanks for [plugsync~] tip. I tried to ultilize new knowlage, below is prototype of hidden recorder device.
One the same device for every track (it generate unique file name: track number/track name/actual time).
Unfortunately outputted files are different size.

I quantized time of start and stop recording to actual time (in seconds) plus I added 3 seconds as safety margin.
I used value from output sample (of [plugsync~]) together with [/ 44100] for achieve quantization to every beggining each second. Probably it is a mistake, maybe I loose exact timing here.

If you can, please check what mistake I did, thanks!

Code: Select all

<pre><code>
----------begin_max5_patcher----------
4710.3oc6cs0aiabE94s.8+.gPBPaxZ149vYeK8g9ZKRyaAAFzRz1LqDofH8
lcaPyu8NWntPIRyCk3PRmFrIV1h5xb9ly4LemKyve8O+md2hGx+bRwhfOD7i
Au6c+p9Ydm84LOy61+Duawl3Oubcbg8EtXY9lMIYkKde0EKS9bo8BoYqRWFW
luKH+wfcIKy2sJM6oCutGyyJKR+OIlWKFEh1+7aiKW9r9Edu9sT5FJJDVe8.
rRZefirODEhB9o8uqrW1jlsNozNlvm9cjEuw9cr361kFuN3umud0hSdW4uTt
+scXHjtx9Fxe3muCKWXex+6e9OYdT+v6AiLYI+h9i3RfYUx53uDPQnCWxMHJ
+x1Dm.u3gXMRcT55AVQYJC5PcfDWzATQtNnB2.TQDCOTsKnLcSx84OdeQY91
6uTK5Bj65PMA1hZjHmpEE2ArgFNXixFdXqnKXqWPSjEZ3QNngNdFeTte0nh2
U5OUJBlaMDoDGtQFQUJrOvss6R1FuK4tx76bf1PiXTgU2hnbZZnQzHjn7gQX
6HVuPEqlCQ5bkiFQ6ORjecM0r8WurwXVaLLZz8MQP9hX.F4GlAbok9DWYQIA
d7XFfoCOVUF7PvCc.Sue.fKJwwmhDx8gpEoA35Fr51jTTD+TRClcIkA2MzNr
4RqmZIlbBDIFCMJOPL3uEvX3WyxKUGjyUASXkyVCYIDvnimgGyCFdFKJm0k+
r8DbtKfO6CULOGEaOrGHB7sATOnUUgQDJL+SCYfddfdYpGQHrk4TzXhP2PLc
O7RYYdFXB.MJ2rPAlS4Bs7JIgJJBK0+NwxRx7ytri.HgdvCbQxZsLDf51yxs
shtiBcUxjFb8gl7pPjdXIczfubthDREXl1LgJhz+ZDVvF200oHeD45+9G9tu
+GFZzJhqbAcXWcpybRNfAqxQ9fNc5qQm13C9lVQmHbIXSXwoHz3wllcKqn+x
lGR18asiKEoOkEu1.MOtNO9z0ozWwNsGhZDsvgbEGGI6l1HO5jL4V248l7UI
0Danlk8A9tAWWsVZ.cbtaKRVYSEPveYSwecw0BRDW5tq.oJJ1PVhCLnzTv+r
n2l7p2aEhUiMuZFwO9rr+qS+VW9vUFHmSKi3b4y39wKFqoEFouUhKYuNVDar
iKgRdaDWxdDhgF83RnSYbIDMoxCwknD9ItDxau3RpVnm5RI6XFWB9FJY65jU
PsM1tKoPyCHtLMO6T41EHF29SGMZZMwtIV2tpgrGx1m3QTyeYmq7zfJUd1x7
046be5nPESgHu2Ray8C7YyCckpaen+oCf4e9utpZ2FIcIn0l3QwH11DbODvK
dvCgqpHHb0Xm+ZLyOw4dhZx.gQJrKe0TqlDiMdg4J8ikzooBnOkgEY803pBK
GOhMAwvCCaW+xSEeIa4u0ShytXb0+x5zh5OwgeoaJ1Ph7UqlQETdjlbPD8vu
JMomhJXxANBOUS4XwGg8VDuY65jfk4ubxU6cDuDdHNRSbhZAmH8ui09shDiR
juBejIS34mqMlDNmS3SpuVM238gbdU2mva6yBF+hgLrFkWfbfKUzFh6fIGj6
3tc0PtHxUsOTaeViOjeC42Yc5mRBOKXoOEu6v.5jq+i3e5VlCHtF4vkxKlKw
NcPe1DBlMCFs9dZCp2FuSKAkI6tOIK9g0I.nVCfFzwXpJh+Txp6iKK2kpAmj
i+VQEXuGsMn45WRxeb+ye3BmNH2juROqX+dIxCZe0dIqyydpwYExgYkK9HSy
pmT25efoYez7AVy44EeDU4rswqml8Xtc3z3.3krTGT17ky2sJYWqezqRd7Ut
Zw1jjUqS2XArlkthxjsEuxH+SoEoU5EM9JRzpCUp14O9ngjfQC6mZ7k94s4Y
lUPaezDmkkWYPbXNrcPq7KUJrMOqrWSIrkK+py56MYIMCKokZ+OmXyzL19b9
txlzEWT8hqbDc7W7rmoaxsDp+9kLkr1j6i4gaIxLzqze3R5ObI86OWRmyO8Z
Xh5p4G1woQptIpnXWp4ktx42zG1nyE0CMjVYdwW17P95AeKOPTgLEQphzXGJ
JLRpilRG3dU27M3oKoYJk9n8Y+Jr9meEw7CpOPMBigYX8hllJLpPnHMBVko6
wIejHOjss3GJ7Q0yHhPkhyhnZHBwBIHIkZphTzXpj4ixYuKNqXcbYRvlhfme
9Ca17ghh9qrAJERZGaQDdjQiSHCobhqnbT1fmDoFco4icaSEcg.FBM7VnRMn
J3biUIiGJ4BNUicxQrUtinuEZgPElEpckIkDSJzzq.PU5vAF2ZqHkuEp8joB
l6a1xHzjzrkROrgcW9bb1qxma.ZCGi4HlnWAvtHoFvnLLV4uBbRaZE.urIch
2r0fUAZngvNbccPbItZFb57+fsoKIZqTpVcTq7oI7pjXQzdrzDj5HrKU7.T9
O9.49u6kUo42ik2gtifvj6k2ww2ocP8KweZbvVl95XLkxzdCornPEWfHZibk
JTR45UTFKDF6ghY8Cld27CK5H5LNIDqh3lZ1YhPSQoHLq41ktONOkFkVLmQM
UETDJiHLIt4O1d1OHCPuO3gsGSwit8I6uEP5rYjug5tFIO.qbN8.r55ejWgV
HYPnExU9oT25uVPsv8qiecrlDRDpWWhI09N4F5hBKJJDgbrFQoiUGcwP9ACS
yFAHTpClSvHVCYRHEIvbsmSc.JZ8PkIFuQBCwdZ6JCdCKeSM4sYEcNWpLAHS
0LI0A2wLKoiwzwiejvCqomuMIK3qvA50uSV3ykpkxCKUWcpKLNIgwGMO31fM
weL4wz0I1A2PCaJjYECc.etcJu130ZnFMlY7CeL3L6PzUTgZEmwH+eJYWwYb
.d2h3saO44OqvMah+YWmgxOlgbsL3dN7wmaWhoRCtOB0wzie3K4D7x1zDtD6
wp5+azonjdd9o04K+XxpZYlewpjG60mhwV43a3X6rt+Gm8RSyNmlTsu53WVW
deM0BRXyufGiWlz9auYpAuawS6RWkmYFH0eulme+W4OV0SNledxn29Rxh21z
auLOe8Cw6NoLPGm30lSwYoahKSLaBIqkL536Lcy1cotfBN9jtJl7bwxc4qWW
+SycoO0zkVoUNVl7KoqJe9rR1T+zVqlp2ol60uvqZ1eVr34adPGdSvlxmCtK
XU7Wz+7KIw6BtOv7Daz+eQs2YiQqeZAwN24vIZAsQoD4prKKxc19vujJYCNG
vm+M1hhS6qm2Fo7ZUt5fK1gG6qc7jzmsy00.xQU49V31eyLHP7vivpwFgS6B
gabWqdU.rzsGLOcOMM9.La3A3y3ZUGgs4OoCGD2Fr5vSAQ1xVntc5V8GVwsA
qzwUusvtxxiA+iO70o2+0E5+6zDR4EX1cDgHhPgJDxRqEyh.3jfN7fMZbA6G
2kuodst6O.i5DfYt8yNSUgy.zi6v8PMNv8.ek+tDdE1MZKiImZ3M52yvKYxg
W93Bu6RdJ4yaCB+l69Kgeye8q.PE9z++lbIyDLKl6xrZD2qL13s4rvGNismX
FWKsr1Jh.xUMJ29ziUEIw4nUso.QmSAl8FI2btZXiilKa9CsspGL31Dsx5SL
tFEea.t6YuaxeiY6dX.dJokCHfdy56Z82f8vxk1Nkzhlm9kdQaVadE01nA.C
+tMKDU0ln109hnK5f5qwBwDtiIPmH6DEC0rSpK6d3tLadsd1ttx32mrNO9hY
1Vr4dE6o3kkZP+gmpsUuiHRFG+9F+sKft5m7qmdktaQ7yzWtrUwO+E.okwgt
YVv0zw.z83v5fbHcQd2cRNftIu6NJu6tJGXmk2c2kCqCyauKy0S7XiQs9QRc
CaPMaduZ3bfMcNfFOGPym2YCn2ilPuuMh9Yduq+GiwRlVMt04+hWIoq49X7E
WcFNSlNR5dfOx46vktOdYZkagBafI5wEq5GuZf7FHxwOaxqgkM4akalKtjH2
t6UAfalm38R3QpQNemXeZ.um0qaWNWc.RHlBVuZjcjyiw+Ycvioq0NyCz.yy
AFe32aNPxK2Eu7i2XInff71PLXtpiTcdc52.NZSo1bO+Yb0oeJozf49UyV3x
ejymgb5zro62VFikhskMh9pFrvqHL4jDfVctyFMQ9NDMD8iCBfD5y8aMcagl
ZcVUeBLcz1FsEUkHallXtrXAJgG9aQU4DXg.vCz6GDO8Ur+hZ6PZZvAZZa.s
OVh8Ucze1JqOmVbuqySBVFmkmktTGsk4lQTle8TUMC3VqkfoSHMmnYcjJLQU
5Oi7ZjJR9ruoAZKklLqWypSL7paEHli7lKUP22zYXnI6rVl.wUGyiG+Q2Sdt
4Kd0jm6Ln9xwF7hG3g1ZPM5gOc2M1vHPJUI0kJZ4jGDEBO1N32kq4NU9kfS6
iWu.xL2MtPmCppCV8IBjmF97EI69TWEw71YqvDN9ftNiTRltvRIH5uWH0Op7
M4DwIGbySJeSzX2bfOkWlCmlYiayRe37pZIYpqYVbUEs1drbDcdMxsyhoTom
dCj.L6zqnTD1dkv03D7oqTDXpGn369dWzUOU5N4KkTw99FootGAJ8cTa5P0F
F62Jt157M3xscfNDQ1D4vjpMMJDjAcES8iHx7ZFcaiW9w82FRpeyHwGd2Tt5
xPc2GRnHI.aOoer8TSwFpnmaph2CeSV..6qh.sZqsY1dzXVjj4amer1l.F4V
o9kry00A0kec8vMMmfQloAl6vfxjdbojHsGFTbr+yxpnstDNZRlYPl+024jW
A9O6.CnceRZ5.JkxbmbwdXhn+ckwpv4cxac0ZqTgI++D5iqtYTQEt6LCSEnO
xqFrJtribfr+VTv9GGJkcGZ6JhLwsgOFezVLxA60MbOfXKpBhmjcClXrgV6t
O12PKFU0r0UX6.zy0WS44wiN11c6kLDfq6PhXO3xlDEWJYNWsqHW9XvXlOq1
kn0haexAFfIUTsso6sibyKnEzoH+kcK2K4UjMdevYRwpjhxzrCE84GODujV9
q+JeNc0pyNyBbGwDq1lqWupZTF7SvmXuNA.CV.PyOAvLrHfE.97T.fOCvlmB
.ba.57zF.tJDY9I.BnpPjYpQr.pJTSNbmAB.E75.MIpyAA.+FW.Dh23BfcXA
2KjX1I.f0fzzzlkS.l9hGnHfmmhfocufJAJ00JBlcstoI+bGXKLp6d.Ws+h4
NZzYDkaataaMp4gfapK6a74NSyG4w4Nj6D6R5Z5byeMeD744x+MpS0lHvloh
.CtHPu1XY4T6tfhVcazkDc3u7rvQ5mvcc1VblSbbGSER9g+xyBGseNNlgYgn
uhvLz9wRd.VPXlcgwrLH.ysNEfSClsm4LkEmpGSDQyS6gFQ2WUHlkyDxdLSH
lqyDRnyDzqmchr5NXsqcoDJwg+xyF7jdnlIlqpYB3yPnqUFDJ2ofivdT+c5e
44kUfmWiYpe.SWZBMy.yyTKAOq.7YJ2dvR.YllXChDtYf3s9jfbtlgBvRvbc
J.bNJmmy.fyxv7bk.voWUhlkie6vh54rqNqj.77TB.ESgb9NCfeSqC0uRLL+
TgZDXaQDnySIfAVIhNOoR.mS87Lc4X34mYdtVlnGlwy2Y.X8M07bFPAdk.Jd
9J.vhqWLeE.PsbAcdV2QL3Z1gQyzbC0KA3sMWhYpD.ulOySUHbul.lecuoMs
sbPBfs5sn4oDv.KAQySAfBV.DySAf.V.XySA.CV.loVwHvBvLjLDX+ndnNS6
uvw6ZpccHDc7V6Zm20Qu7psdqL8o04ODut5tH6kGp9ftYl148K0FdyGj9yt+
+5.456Yop6GvmOAu+tBbWMWeKSp0YR1v7YKykMduJF7XCzP6bAXjFaDHiMLe
9N1HSyXix.M3p2aHiFvggL3nSCxcFU71FbSxXiCZrgYyXf6r8NznYO.RkCKl
D6AJLOInowKmBxfaZVcfUO8is1LBSiJGH6AtpuCNABGFIvLy9B.6NvJUxPJE
yYzpmZXF+TPfKcZLYn0B.40VeCMMCNZmCN1zgbv7DNAFzfFbzIZ0Wi1jrSN7
Syfi.ivGdZnF.ZMDxzva4bF5fJ.2XM3jRPCtogTECCYEBtZR7ywv9Y42gYZU
LiGbL+L1nRhlkBEqvFVJzPESIXhyYur+4GnPRhfHKSiBZDn05TSiN.FDvEQm
nHMgkVnog2OrHMm0trYnYrKa1DEGLHcN1zLsxAQvhMMgCgYyXNLXLL60Iwf.
ChlfbhhUCVVqlnvg.s3JSMcosp6nbISV0fHcu7EdxFbXH1pSgiDhe3MyvpPA
lRYDC+X7kI7COPI7CTnlxoYMDBnA2zP3KBhRIcZXsvjfrXPSiuFEHGgXzDwa
AAK4KnoQsiCMz1I.4.s5KexrV6dN81YsXdB8C+OvTI6hu
-----------end_max5_patcher-----------
</code></pre>