• Did anybody worked with the elastic~ or elasticx~ object in max?
    It looks like a great object for a new MLR version...:-)
    have a look:

    best wishes

  • http://post.monome.org/comments.php?DiscussionID=2708

    tehn suggests open source distribution problems...

  • HavenĀ“t seen this thread, you are right....
    There is also a free version: http://devinkerr.com/
    I am going to try this one....

  • elasticx~ is new and different from elastic~

    it seems like it will be released in a different way than the original elastic (using elasticmax's own technology instead of licensing other IP), so we may actually have a shot here at incorporating it into mlr.

    i'm emailing them now to ask about this.

  • As stated before, elastic~ (although not free) uses a superior algorithm (compared to fft and common granular), and is less cpu-hungry. On the other hand, issues with opensource distribution and less flexibility as it is not done in Max.

    Check out Mattijs Kneppers granular time stretcher (available via C74 share pages), free and works like a charm.

    Putting it into monohad right now...

  • The one at devinkerr.com has latency due to fft algo which granular ones don't have

  • Simon from Elasticmax got back to me and we're going to try to figure out a way to make this work.. It will probably mean me buying elasticx~ and building a stand-alone app out of MLR so that no one can open it up and take elasticx~ for free for their own patching endeavors.

    the goal is to keep mlr free.

  • Hope elasticx~ is worth it. I always thought, the goal was to have "open source code" rather than "free apps"

  • > the goal was to have "open source code" rather than "free apps"

    the goal i was referring to was my goal in providing an elastified version of mlr to the community.

    the previous discussion of elastic birthed the idea of a "paid-for" version of mlr that includes elastic. the paid for version would allow access to the information about the modification, but even then, there's the obstacle of max, which is a proprietary development environment.

    so, while i agree that having open source code is indeed a goal of the community, that goal doesn't necessarily prevent us from dealing with software that is closed source, like max or elastic.

    in this circumstance, i believe that providing functionality to the community is more important than sticking to an "open-source-only" mentality.

  • You could also make an elasticx~ version and not include that external in the distribution, allowing people to make the choice to buy the external themselves to get it to work.

  • I'm not sure if I like the idea of not being able to open the app. There must be a way of locking th elastic object so you can still edit the existing patch.
    Your way is definately better than nothing but I think being able to costumize is a big factor for me at least.
    Just my thouhts.

  • @soundcyst

    you are right, especially from that angle, most of the monome users probably use runtime and don't own max, so they wouldn't be able to hack the patches.

    still, for the ones actively implementing, not being able to open the patches and learn, pick and choose is a major issue.

  • kevin, did this ever get anywhere? i'd love to contribute. no worries paying for it. seems worth it for the tools and efficiency it seems to provide.

    as far as distro, yes ideally open source is best. but efficiency is key as well (meaning maybe devin kerr's solution should be avoided). i think there should be some option to release it as a standalone patch as well as a sourced version where everything but elasticx itself is included. so, just put a patcher in place of elasticx with the same number of ins/outs. crack open the patcher and there's just a comment that says "put elasticx here."

    that way, at least people know how its coded and if they wish to buy elasticx and change things around, they can. others can just grab the standalone "mlstcr" (my proposed name :) and still get the functionality.

  • There is also free-elastic~. It's not totally the same thing but seems to work well.... And it's free.

  • yeah free-elastic~ is great, and free, i used it to create a basic wireless audio pitch and time XY scratcher thing with an ipod touch and it did the job really well..

  • that's what i was referring to. the other thread on this topic says that that object creates too much latency and cpu overhead to be useful within mlr (especially when we're using four, six or eight of them). i've not tried it myself to verify this, just going on what others have said.

    but yes, free is good. somewhat cheap and fast isn't bad either, tho.

  • ummm. didn't really get anywhere with it. if i don't go to the nomeansno show tonight, i'll bang something together..

    i don't think they ever emailed me back regarding use of elasticx~.. i actually bought elastic, and hven't used it much.. it's not quite compatible with groove~ (inlet/outlet anyways) which is a bit of a fucker, but easy to abstract away.

    if i wind up going to the show, i'll have a stab at it this weekend.

    erm, my plan of attack.. now that i think about it, would be to add a column to ch.mxb with some kind of pitch control (maybe in cents?), do a little math to get the pitch change relative to 1.0, then send that data over to pl.mxb via the already established coll system.

    you know, if you guys are interested in giving it a shot.

  • ok. so i bought this a while back and have never really gotten it going. i tried using elasticx~ as a basic pitch-shifter of mlr's output but there were all sorts of artifacts and it basically sounded like hell. maybe it was my fault, tho i did follow their example and it's a simple patch...

    also, tried just pulling open the pl beast and changing groove~ to elastix~ (and changing the min/max inlets so they line up to the new ones in elasticx~). this basically just doesn't work. it will, at first monome press, just play the first 1/monome-width portion of the loop, quickly looping thru the other led's but not playing them (kind of like when you do a reverse loop with the last button as the endpoint). then if you stop the loop, it will play correctly when you press a button in the row but they all just play through; pressing a new one (further down the row or previous, etc.) won't make it retrigger to that point, just trigger again at the current point being played. so...no idea what's up there. tho admittedly just dropping it in and expecting it to work is a naive approach.

    then i tried just dumping it into the groove~ object in the basic mlr tutorial patch, hoping to start debugging the source of weirdness. the results were ever worse. basically didn't work at all.

    i'm a bit confused, as my impression was that elasticx~ was supposed to be a direct replacement for groove~ with added on tools you can optionally use. doesn't seem to work that way so far.

    anyone gotten any further with this? anyone actually made any functioning patched with it?

  • old question but...

    from what i've read you need to prepend the position messages with 'start'


    (start 500) into the first inlet will jump to 500ms.

    i'm probably try something out with this tomorrow..

  • yo!

    bought the objects.

    got it working in mlr 2.27 in about 5 mins. it's pretty damn awesome having independent speed and pitch controls in mlr

    will clean it up, add some press command features then do a video.

    not a big fan of the object not being open source but I think it's pretty much made my copy of ableton and max for live redundant. at a minute faction of the cost..

  • ...and maybe share it with the rest of us??? :-) I'd love to see how you've implemented the objects into mlr.


  • indeed. looking forward to video :)

  • yeah, for sure i'll share it..

    just feel weird about it not being open source. but yeah, it's a hell of a lot cheaper than ableton and max for live..

    might be a day or two before I get anything out. wanna make sure theres enough video/doc of everything it can possibly do so people can make an informed decision before purchasing the object

    tis fun tho :)

  • I always thought an mlr with configurable segment points would be cool, and I think elasticx would make that easy. It would be like abletons warp markers, so initially you'd have the usual sample split into 8 equal, but you could then drag the points so they weren't just equal, thought itbwould be cool for drum loop samples.

  • yeah, i've been looking into that.

    theres something similar in the elasticx demo video where they warp a sample with an lcd object but they don't appear to have shared the patch.

    there's quite a bit you can do with these objects.

  • what about this:

    It looks a lot like the warp markers in ableton

  • ahh whoops, was looking at the elastic~ forum and not the x~ one.

    thanks for the heads up :)

  • I'm just glad that you're diving into this :-) glad to help

  • excited to see this. i get all kinds of glitching when i drop it into my mlr patch. not sure what's up.

  • to be honest i'm not sure how far i wanna take this. implementing warping etc would probably constitute a rewrite of the whole gui etc for starters.

    i'm already in the middle of writing my own mlr-like looping/chopping/mangling patch...

    heres what i've done so far so you can have a look and a play if you got elasticx~

    files modified are: ch and pl.
    works fine in max5 from what i can tell

    haven't done the 256 vers..

    *** requires elasticx~ *** - paid external, not included

  • I'm about to make elasticx~ open source give me a week. Anyone wanting to try to improve the software would be very much appreciated. please feel free to contact me on info@elasticmax.co.uk

  • Well good goddamn, that puts a smile on my face! Very keen to see this development! All the best in your efforts...

  • amazing to hear :)
    i promise to put it to good use!

  • RAD! maybe i'll port the external to pure-data :)

  • OOooohhh this is sooo cool. (even after buying it)

  • yes, the cost of the object was never my objection, i just didnt want to use it and then not be able to share my patches, so this is very much good news, share and share alike! I trust this move brings you much good karma my (newfound) friend...

  • going to be busy loading loops and samples if this is true...searches library..

  • awesome news jfabric!

    i was working very undiligently on an elastic-like external based on the rubber band library, but never got anywhere with it..

    and i //did// go to that nomeansno show. and it was a blast.. oh the joys of internet past.

  • this is good news that's it'll be free. but after paying for it, i can never get elasticx to function properly. i always get weird phasing and flanging issues with it, even with the default patches. i've written in for help too and have never gotten a reply. money well spent :(

  • i've noticed a few inconsistencies.

    it seems to displace the waveform of the buffer by a noticeable time.

    when triggering a 'startloop' message to an elasticx~ and groove~ object at the same time i loose pretty much all the kick drum on the elasticx~ one.

    that and yeah as joe said i can clearly hear phasing and flanging on the elasticx~ one...

  • honestly, i've had much better results with the (other) free version: http://devinkerr.com/category/software/

  • the only issue with free version is that is uses a fft, so introduces some latency. We need to get a kickstarter or something rolling for someone to write an open max object for general use timestretching...as i said to those elastic~ folks, its not about the money. I'll pay for the object. I just don't want to worry about giving away what i make with the object...

  • and when i was googling around on this topic, i found this vid. I love his accent! I may sample this whole video for a track...


  • Any more news on when elastic~ goes open source?

  • i dunno man. These guys have not established a reputation for public communication. I still say we get a whip round, pass the hat, and pay someone to write an open-source implementation...

  • I would donate to whomever we elect to be the dev on this project.

  • @01100010 Same here.

  • any programmers with time on their hands want to wave one of them around? Bueller?