dx1200

I'm surprised this hasn't appeared on the forum sooner. I hope I don't get in trouble for posting it. Perhaps some people might feel bad for the guys who wrote elastic but this chap - Devin Kerr has written a free version that works quite nicely in the few simple tests I've done. Check it out

free-elastic

I don't think you'll get in trouble for posting it. Shame the guy called it free_elastic though as it doesn't use the same algorithm and works completely differently. Just causes confusion.

Having said that, it's a nice patch actually and proof that you don't NEED pay for externals to get the results you want. Though it's certainly faster and easier to buy the object if you need it.

Just to add to that, it's actually a very SIMPLE patch that anyone could make with knowledge of the max tutorials. I haven't tried elastic~ but I would bet it does a slightly better job than this?

ell, fft is known to not be able to exceed a certain level of quality. too many artefacts in the processed signal to be really convincing. nevertheless, a nice effort, and thank you for this!

add-on: an - fft-typical - delay of 70 ms is certainly a drag during a performance...

Actually I have tried both and the real elastic~ has far 

better quality. That being said, free_elastic is free, 

can't argue with that. I guess you get what you pay for.

Actually I have tried both and the real elastic~ has far 
better quality. That being said, free_elastic is free, 
can't argue with that. I guess you get what you pay for.


"Actually I have tried both and the real elastic~ has far

i knew it! why is my goddarn paypal not working/ rrrrr. i'll get elastic~ tonite. it's a real deal for a good sounding, professionally usable extension i believe.

"Actually I have tried both and the real elastic~ has far
better quality."

i am pretty happy with this free release. I gave it a check out and am happy for what it is.

Sure it is not a naked woman holding cheese covered nachos. But it at least does a good job.

Plus the fact that they also gave the actual inside of the patch itself makes it better in the long run, because then you can add your own things to it. Make it better, faster, etc.

I am not saying that [elastic~] is bad, no. I was thinking of getting it myself.

But now that DX1200 has shared this valuable information, i think i will stick to not buying it. But instead make the [free_elastic~] better and more in tune to what i will need it for. Maybe make different ones for different jobs.

I am not saying that [elastic~] is bad, no. I was thinking of getting it myself.
But now that DX1200 has shared this valuable information, i think i will stick to not buying it. But instead make the [free_elastic~] better and more in tune to what i will need it for. Maybe make different ones for different jobs.

I agree, calling it free_elastic was bad form. Second, compiled code will be more efficient allowing more instances and greater precision. Try using [poly vs 1] sometime to see what I mean.

Externals can natively work sample by sample or even over-sample in an optimized loop to give better quality at lower resource utilization.

It's great to have a free "open source" example but equally great to have access to the same DSP that professional DAW's use. Hats off to the elastic guys for sorting the licensing of an industry standard process and making it available in Max/MSP.

The core idea of modular patching environments is that you can build what you want on your own terms. At present, 3rd party external developers will not find a large audience amongst such a DIY userbase, however I would be sad if these offerings didn't exist (Tap.Tools, Elastic~, iCE, Litter, Ms.Pinky, Etc.), as I use some of them everyday.

Which brings me to my final point. Most developers of externals are either selfless humanists or have a secondary business model which utilizes the externals in another form (e.g., Nortron utilizes iCE). I hope that Cycling continues to make Standalone and plugin development a priority for Max5 as it allows developers to offer core technology to the Max/MSP cabal while selling it wrapped up to non Max/MSP users. This model benefits Cycling, Cycling's user community and Cycling's development community by encouraging technological growth on all fronts (Not to mention the c74 marketing gambit of Standalone's and Pluggo).

With this in mind, could we get a feature in Max5 for building Standalones with the sources encrypted/encoded? This would help keep the above symbiosis intact.

I agree, calling it free_elastic was bad form. Second, compiled code will be more efficient allowing more instances and greater precision. Try using [poly vs 1] sometime to see what I mean. 

Externals can natively work sample by sample or even over-sample in an optimized loop to give better quality at lower resource utilization. 

It's great to have a free "open source" example but equally great to have access to the same DSP that professional DAW's use. Hats off to the elastic guys for sorting the licensing of an industry standard process and making it available in Max/MSP. 

With this in mind, could we get a feature in Max5 for building Standalones with the sources encrypted/encoded?  This would help keep the above symbiosis intact.

> With this in mind, could we get a feature in Max5 for building

> Standalones with the sources encrypted/encoded? This would help keep

There are two different things concerning "keeping the symbiosis 

intact": If you want some copy protection/DRM scenario, you could 

certainly setup such a thing with the existing versions of Max (It had 

been done already). If you want to prevent any reverse engineering, I 

doubt its worth the hassle, usually its way easier to rebuild a program 

from scratch, than tear appart an existing application, study and 

understand its inner working, to reuse parts of it in a different 

application... I can't imagine anybody would do that. If you have a 

special technology involved, better get a patent on it, that would at 

the same time publish the technical innerts and protect agains abuse.

Once the main reason for setting up a patent system was not the 

protection of, at that time non existant, intelectual property rights. 

It was the need, that the technology behind inventions should be 

published for the benefit of the whole society, the knowledge had to be 

The only reason why elastic~ isn't free, is because its technology is 

The free-elastic~ has nothing in common with that patent...

Anthony Bisset schrieb:
> With this in mind, could we get a feature in Max5 for building
> Standalones with the sources encrypted/encoded?  This would help keep
> the above symbiosis intact.

There are two different things concerning "keeping the symbiosis 
intact": If you want some copy protection/DRM scenario, you could 
certainly setup such a thing with the existing versions of Max (It had 
been done already). If you want to prevent any reverse engineering, I 
doubt its worth the hassle, usually its way easier to rebuild a program 
from scratch, than tear appart an existing application, study and 
understand its inner working, to reuse parts of it in a different 
application... I can't imagine anybody would do that. If you have a 
special technology involved, better get a patent on it, that would at 
the same time publish the technical innerts and protect agains abuse.

Once the main reason for setting up a patent system was not the 
protection of, at that time non existant, intelectual property rights. 
It was the need, that the technology behind inventions should be 
published for the benefit of the whole society, the knowledge had to be 
spread and uncovered...
The only reason why elastic~ isn't free, is because its technology is 
patented...
The free-elastic~ has nothing in common with that patent...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


Stefan, thanks for your feedback, good points. Maybe I wasn't clear enough. I'll try to explain,

DSPaudio provides the iCE externals for users in the Max community and a sequencer built using iCE in standalone format for electronic musicians at large. Our externals and standalones already have a form of copyprotection which we created.

With Max4.6 the standalone package obscured code enough to make the hassle of deconstructing it greater than the hassle of coding a new patcher. It encouraged would be hackers to just DIY (as you pointed out). With Max5 that is no longer the case and our IP is exposed unless C74 adds a feature to *obscure* the standalone package data (which was standard in 4.6).

Some of us are not comfortable having 3+ years hard work put directly to the public domain with the new Max5 standalone format. Imagine if XCODE or GCC was suddenly changed and Cycling was forced to release the actual code of Max/MSP with the binaries? This might be a problem for them and this is exactly what has happened to not only us but other Max/MSP developers.

Our feature request is simply asking C74 to give us a binary non-Max5 loadable format for the lightweight protection of standalone applications. If someone has the time and energy to deconstruct past this first layer defense, fine, but security through obscurity is a valid concept and works everyday in practical life. How many Max 4.x packages have been decompiled and spread across the interwebs? I don't know of any...

Finally, I was trying to make the obvious point that by supporting commercial developers like ourselves C74 wins in that we can give back to the community core technologies that we 

create while using them in standalones to support the company.

It's a nice model and I hope they continue it.

With Max4.6 the standalone package obscured code enough to make the hassle of deconstructing it greater than the hassle of coding a new patcher. It encouraged would be hackers to just DIY (as you pointed out). With Max5 that is no longer the case and our IP is exposed unless C74 adds a feature to *obscure* the standalone package data (which was standard in 4.6).  

Finally, I was trying to make the obvious point that by supporting commercial developers like ourselves C74 wins in that we can give back to the community core technologies that we 
create while using them in standalones to support the company.
It's a nice model and I hope they continue it. 

>Some of us are not comfortable having 3+ years hard work put directly to the public domain with the new Max5 standalone format.

The Max 4 format was never represented as providing any "defense" against reverse engineering. It's really easy to take the old collectives apart. I think at one point we even thought about publishing the spec for it.

If you wish to protect work that you have created in MaxMSP, the onus is, was and always will be upon you to sort that out to your own level of comfort.

"The Max 4 format was never represented as providing any "defense" against reverse engineering."

I think, Andrew, that Anthny wasn't trying to point this out. What he was trying to point out is, that it would comfort the needs of external developers to be able use a slightly data-theft-preventing feature - intendedly there in max 4 or not - in version 5 still.

i have an understanding for this need myself, especially following the ideas Anthiny presented here:

"Imagine if XCODE or GCC was suddenly changed and Cycling was forced to release the actual code of Max/MSP with the binaries? This might be a problem for them and this is exactly what has happened to not only us but other Max/MSP developers."

External Max/MSP developers increase well the attractivity of MAX/MSP for the benefit of Cycling74. There's no obvious reason why C74 shouldn't support those developers needs to a certain extent. It would only do good in the long run.

I have to give a hearty "Amen" to jayrope's comments. As a developer (not with Max/MSP, but elsewhere), I couldn't agree more. This should be a feature that C74 implements...period.

I have to give a hearty "Amen" to jayrope's comments.  As a developer (not with Max/MSP, but elsewhere), I couldn't agree more.  This should be a feature that C74 implements...period.


I'd like to explain myself a bit in regard to the whole elastic~/free_elastic thing.

I was not trying to replicate elastic~ exactly, but merely create something simple that I thought functioned in a similar way using max-only objects so that everyone in the community could use it. For me, free_elastic works better for what I want to do and it took minutes to make. So view free_elastic as alternative, not a direct replacement, to elastic~.

Also, I did not intend to discredit the fine work of the people who made elastic~; it does what it sets out to do very well and is very CPU efficient.

That being said, I was frustrated that certain aspects of the external were limited so that the results would always be (what the developers viewed as) "natural" sounding. This type limitation would sort of make sense to me in a program like Cubase or ProTools--but why limit the customization in Max, a program built to allow nearly infinite customization and control? From my perspective, I love having the ability to totally destroy the sound by slowing the speed down to almost ~0 with free_elastic. If I want something to sound as “natural” as possible then I use Ableton, etc.

If I have time, I’ll try to put out a granular version/option for the people who are interested, although I realize there are already many in existence…

Are many people interested in a Max 4 version or is that is waste of time at this point?

I was not trying to replicate elastic~ exactly, but merely create something simple that I thought functioned in a similar way using max-only objects so that everyone in the community could use it.  For me, free_elastic works better for what I want to do and it took minutes to make.  So view free_elastic as alternative, not a direct replacement, to elastic~.

That being said, I was frustrated that certain aspects of the external were limited so that the results would always be (what the developers viewed as) "natural" sounding.  This type limitation would sort of make sense to me in a program like Cubase or ProTools--but why limit the customization in Max, a program built to allow nearly infinite customization and control?  From my perspective, I love having the ability to totally destroy the sound by slowing the speed down to almost ~0 with free_elastic.  If I want something to sound as “natural” as possible then I use Ableton, etc. 

If I have time, I’ll try to put out a granular version/option for the people who are interested, although I realize there are already many in existence…   

Quote: devkerr wrote on Wed, 03 December 2008 23:23

----------------------------------------------------

> Are many people interested in a Max 4 version or is that is waste of time at this point?

You sure have my vote for a Max 4 version!

Quote: devkerr wrote on Wed, 03 December 2008 23:23
----------------------------------------------------
> Are many people interested in a Max 4 version or is that is waste of time at this point?
>
> DK    
----------------------------------------------------

You sure have my vote for a Max 4 version!


I think having a Max 4 version is always good. 

Especially for most people who are still on Max 4...

I think having a Max 4 version is always good. 
Especially for most people who are still on Max 4...


> With Max4.6 the standalone package obscured code enough to make the hassle of deconstructing it greater than the hassle of coding a new patcher. It encouraged would be hackers to just DIY (as you pointed out). With Max5 that is no longer the case and our IP is exposed unless C74 adds a feature to *obscure* the standalone package data (which was standard in 4.6). 

> Some of us are not comfortable having 3+ years hard work put directly to the public domain with the new Max5 standalone format. Imagine if XCODE or GCC was suddenly changed and Cycling was forced to release the actual code of Max/MSP with the binaries? This might be a problem for them and this is exactly what has happened to not only us but other Max/MSP developers.

Anthony can you please explain further this?

How can the be a max5 standalone reverse engineered?

> With Max4.6 the standalone package obscured code enough to make the hassle of deconstructing it greater than the hassle of coding a new patcher. It encouraged would be hackers to just DIY (as you pointed out). With Max5 that is no longer the case and our IP is exposed unless C74 adds a feature to *obscure* the standalone package data (which was standard in 4.6).  
>
> Some of us are not comfortable having 3+ years hard work put directly to the public domain with the new Max5 standalone format. Imagine if XCODE or GCC was suddenly changed and Cycling was forced to release the actual code of Max/MSP with the binaries? This might be a problem for them and this is exactly what has happened to not only us but other Max/MSP developers.

Anthony can you please explain further this?
How can the be a max5 standalone reverse engineered?


On 30 Dec 2008, at 12:40, Giorgio Sancristoforo wrote:

> How can the be a max5 standalone reverse engineered?

I've not looked into this in detail, but I assume the collectives are 

just assemblies of JSON files, and since JSON is more readable than 

Max 4's binbuf format it's easier to do something like throw EMACS at 

There was never a guarantee that collectives guaranteed security 

against reverse-engineering - that was never their purpose. The fact 

that compilers for conventional native languages produce output which 

cannot be reverse engineered is to some extent merely fortuitous - by 

contrast, look at the market in Java code obfuscators.

I've not looked into this in detail, but I assume the collectives are  
just assemblies of JSON files, and since JSON is more readable than  
Max 4's binbuf format it's easier to do something like throw EMACS at  
a collective and crack it open.

There was never a guarantee that collectives guaranteed security  
against reverse-engineering - that was never their purpose. The fact  
that compilers for conventional native languages produce output which  
cannot be reverse engineered is to some extent merely fortuitous - by  
contrast, look at the market in Java code obfuscators.

Nick Rothwell / Cassiel.com Limited
www.cassiel.com
www.myspace.com/cassieldotcom
www.last.fm/music/cassiel
www.reverbnation.com/cassiel
www.linkedin.com/in/cassiel
www.loadbang.net


Quote: devkerr wrote on Thu, 04 December 2008 07:23

> I'd like to explain myself a bit in regard to the whole elastic~/free_elastic thing.

this name suggests it is very very similar to elastic~, just free, while it is really something else.

Quote: devkerr wrote on Thu, 04 December 2008 07:23
----------------------------------------------------
> I'd like to explain myself a bit in regard to the whole elastic~/free_elastic thing.

Quote: stefantiedje wrote on Tue, 06 January 2009 16:47

> The easiest solution would probably be to have files saved in the 

> compressed format, and add a flag that would prevent it from switching 

> to patching mode or open any subpatchers...

Compressed format is just Base64/ZIP (or something similar).

Someone on this thread was working on a standalone decompressor for Max 5's Copy Compressed output. I dunno if it turned out.

Stefan's suggestion has the merit that, if implemented, it would make Max 5 standalones about as secure as back in Max 4 days (ie, still crackable but not obviously so).

Regarding Nick's comment about conventional compilers producing non-reverse engineerable code… I used to regularly reverse engineer parts of the Mac Toolbox from 68k disassembler dumps in MacsBug. It wasn't that hard. I don't do that with PPC or Intel disassembly, but that's just because there are limits to my geekiness. And I wouldn't have wanted to do a complete app that way.

So the protection is all a matter of degrees. And what level of obfuscation Cycling 74 deigns to lay upon Collectives/Standalones is probably largely a trade-off between what they perceive as convenient and worthwhile.

Returning to Stefan's suggestion: I wouldn't go so far as to claim whether it would be easy or not to implement, but at least the bits and pieces (compression/decompression of the plain-text JSON format) have already been implemented. I don't know how hard it would be to hook them up as an option for standalones.

Quote: stefantiedje wrote on Tue, 06 January 2009 16:47
----------------------------------------------------
> The easiest solution would probably be to have files saved in the 
> compressed format, and add a flag that would prevent it from switching 
> to patching mode or open any subpatchers...
----------------------------------------------------

Compressed format is just Base64/ZIP (or something similar). 

So the protection is all a matter of degrees. And what level of obfuscation Cycling 74 deigns to lay upon Collectives/Standalones is probably largely a trade-off between what they perceive as convenient and worthwhile. 

Returning to Stefan's suggestion: I wouldn't go so far as to claim whether it would be easy or not to implement, but at least the bits and pieces (compression/decompression of the plain-text JSON format) have already been implemented. I don't know how hard it would be to hook them up as an option for standalones.


Free-elastic~