jengel

Okay, it's been quite a while but I finally updated it to work with 64 bit and work on windows as well. Please give it a shot and see how it does :).

I have a few too many things on my plate at the moment with a new job. Although, the code is all available at https://github.com/jesseengel/TimestretchLooper if anyone wants to make a pull request / do it themselves. It is on my long term to do list though.

Hi Shaun,

Looks like I'm not going to get live 9 soon, but I took a look at the patch again. I couldn't reproduce the behavior you mention (MBP 2011, OS X 10.6.8, Live 8). For what it's worth, there's not much computation happening in (p CalcPressure), so changing it shouldn't effect much.

You might want to try playing around with the threshold settings. I've also noticed that there is no sensor on the center of the softstep pads, so if you push hard right on the center, it doesn't actually register much pressure. You can get around that by putting rubber stoppers from home depot on the corners of each pad so it pushes down directly. Also, one tweak to get a better response could be to replace the (mean) objects in (p CalcPressure) with (zl sum) which will give a better feel for how hard you're pushing in total.

Best of luck!
Jesse

Hi Shaun,

Downloaded the link, but I'm only using Live 8 these days so I can't open the set. I'm planning on upgrading sometime soon, so I'll take a look then. Sorry for the delay.

Best,
Jesse

Hello,

I'd be happy to take a quick look when I get the chance. The easiest way would be to create a public dropbox or google drive folder and post the link here.

Cheers,
Jesse

Amazing work. Makes me want to get Live 9. They should pay you ;)

Cool Device. I'm not sure if it's a Mac PC thing, but your device currently uses [zl.group] which needs to be [zl group] at least to work on a mac.

Cheers

Helllo,

If someone gets this working okay, please let me know, and say which version of Live, Max, and OS you're using so I can try to trouble shoot.

Thanks so much,
Jesse

DiracLE~ is included in the github folder, but for also, for anyone interested, here's a link to Timo's external

http://www.timorozendal.nl/?p=434

Okay, so I've double checked the dependencies and I think it might just not be getting everything in the freezing of the file.

Please head over to the github link

https://github.com/jesseengel/TimestretchLooper

and just press the "zip" button. That should download a zip file the unfrozen device and all the abstractions, poly patches, images, and externals needed.

Just put that folder somewhere in your MaxPath, and you should be good to go.

Someone please give it a try and let me know if that works for you. Also, if anyone has the frozen device here working, please let me know.

Thanks!

Hey Everyone,

Thanks for testing it. It looks like I originally made it in Live 8.2.2, so I'm guessing that the problem is with the 32 bit vs. 64 bit program.

Luckily, Timo also made a 64 bit version of DiracLE~ which I think I might not have been using, so I've switched them out and reuploaded the device. Please let me know if anyone can get it to work fine.

On my Mac Book Pro, it goes from 2 to 3% when loading the device and 7% when actually playing a loop (Dirac is pretty computationally expensive), so something in that range is what you should be expecting. The reason it's less while not playing is that I enclosed Dirac in a Poly~ so it could free up resources when not in use. I also included an extra bit of code to double make sure that that poly~ is only allocating one voice, otherwise that could take a lot of resources!

Hope that works, let me know, and happy looping!

Sorry, the link is
http://forum.keithmcmillen.com/viewtopic.php?f=40&t=535

Hi Pepe,

I suggest using Tom Swirly's excellent softstep.jso (http://forum.keithmcmillen.com/viewtopic.php f=40&t=535). You can write a M4L device with a "r toSoftStep" object that gets the OSC messages from the loopers, parses them for looper # and state(you could use a similar method to what I use in this device for "OSC In"), and then passes that to "display".

Good luck!

Currently, the device only has one functionality per a SS button. I was trying to simplify the SS so I could actually get around to making music with it instead of just playing with programming.

It would be easy to change the device to allow for more than one functionallity, and feel free to modify the device to suit your specific needs.

I'm currently working on a version that is more specifically centered around communicating with loopers, but still with a single functionality per a button. Cheers!

It's pretty straightforward using the very handy patch waclphandler

http://chippanfire.com/software/wac-lp-handler/

You can write a short script turning the OSC messages from LooperOSC into ones that the lp handler understands

Good to hear it. I'd be happy to hear how anyone uses this thing too :).

Cool stuff. You might want to check out the device LooperOSC I just put up. Cheers

Sorry about that, it appears I did.

I've uploaded the freezed version, let me know if it works for you. Failing that, you can download the externals from the links I provided in the description.

hey zb,

cool device, I didn't know much about hilbert transforms and this device has peaked my interest.

Bug report though, when I put the drive to max it sends full output and stays that way even after bringing the drive back down.

It's a gate that observes any objects you put on a track and only gates when all the other objects are off. You can very easily mod it to be a line~ or some other thing if you like. Its for the workflow of people who use their computer as a big send for their live instruments and don't want any dry signal to go through because of latency issues.

Hey, It seems you need to freeze your device to incorporate your reverb externals.

Cheers,
Jesse

Great Device. Very straightforward and easy to use

Great Device. Very straightforward and easy to use