New! Chipcrusher! - Advanced Bitcrusher, Speaker Simulator and Noise Machine from Plogue

[Liero]

Ever try a Voxengo plugin?

- No installers, just a zip file
- No registry entry created, no registry dependencies
- Single file contains all resources making plugin extremely movable
- No file dependencies
- Zero chance of ruining an installation by moving or deleting files
- Registering within the plugin with a simple serial
- Saveable presets just like any other plugin
- Built-in skins
- Extremely little is needed in case of an OS reinstall or change: just re-enter your serial

Is there someone who thinks the benefits mentioned above are outweighed by the ability to start toying around in photoshop so you can get some custom looks into a GUI? If it's a good GUI that shouldn't even be necessary. IMO anyone whose main interest is making music and keeping a clean OS is going to prefer the former. Just my opinion. If it's easy to do I'd like to suggest an installerless .zip version of your products that would be portable as well.

[davidv@plogue]

Hi

I know I'm not going to win you over on this. There are a few users who have this grudge with what we do (a few on the thousands of users), so I can live with that. However for the people watching, from the way you describe it, it would appear as though the way we design stuff is backwards and unfriendly.

Most feedback we have is about users happy about the sounds and that it works fine on multiple platforms and apis, also, from we gather, they don't spend their time reinstalling everything.

But let me put a few things from perspective.

The first Voxengo plugin on their page, Elephant weights at 17MB only for the 32 bit VST dll, in comparison, if chipsounds were to be a single plugin it would be be around 120MB and chipcrusher would be 40MB, not actually small and host friendly. PLUS If you are using BOTH x64 and x86-32 builds for various sessions on a computer you would of course need to double that in terms of hard drive space.

Now If you are on Mac and use the VST the AU and the RTAS versions, that would put the bloat at 360MB for chipsounds and 120MB for chipcrusher.

Second, if I fix an ARIA engine bug, since all VST's AU's RTAS and standalone are just shells, ALL products get fixed, under every plugin api, across all architectures, where-ever the VST shells are moved.

Third, we have tons of sound files, presets and so forth, its easier to maintain and fix things when you don't always deal with a huge monolitic blob.
It makes us more productive and efficient, which in terms helps speed up products launches.

In short our engine is used not only for _smallish_ 40MB chipcrusher and 120MB chipsounds, but also for multigigabyte Garritan Libraries.

[camsr]

Is it possible to get a zip file installation for the demo? Or can you only set up using the installer?

[Liero]

Hi

I know I'm not going to win you over on this. There are a few users who have this grudge with what we do (a few on the thousands of users), so I can live with that. However for the people watching, from the way you describe it, it would appear as though the way we design stuff is backwards and unfriendly.

Most feedback we have is about users happy about the sounds and that it works fine on multiple platforms and apis, also, from we gather, they don't spend their time reinstalling everything.

But let me put a few things from perspective.

The first Voxengo plugin on their page, Elephant weights at 17MB only for the 32 bit VST dll, in comparison, if chipsounds were to be a single plugin it would be be around 120MB and chipcrusher would be 40MB, not actually small and host friendly. PLUS If you are using BOTH x64 and x86-32 builds for various sessions on a computer you would of course need to double that in terms of hard drive space.

Now If you are on Mac and use the VST the AU and the RTAS versions, that would put the bloat at 360MB for chipsounds and 120MB for chipcrusher.

Second, if I fix an ARIA engine bug, since all VST's AU's RTAS and standalone are just shells, ALL products get fixed, under every plugin api, across all architectures, where-ever the VST shells are moved.

Third, we have tons of sound files, presets and so forth, its easier to maintain and fix things when you don't always deal with a huge monolitic blob.
It makes us more productive and efficient, which in terms helps speed up products launches.

In short our engine is used not only for _smallish_ 40MB chipcrusher and 120MB chipsounds, but also for multigigabyte Garritan Libraries.

I guess I don't completely understand why you need a sampler engine capable of multi-gigabyte libraries in a DAC simulator. IIRC you mentioned years ago that chiptunes was 95% synth as well, and going up. I do understand that if you use convolution, the large impulse files take up a lot of space and I'd definitely not include those in the plugin, but apart from those I see no reason why a dac simulator + convolution engine should be anything else than a <10MB .dll + impulse response files. For reference, the very high quality convolution plugin SIR2 is a single file sized 3,12 megs, the toneboosters timemachine DAC simulator is also a single file sized 2,75 - both completely portable.

I completely understand that it's less work for you as a developer to have a big, open array of files, but don't you agree that it's simultaneously more work and maintenance for the end user (in other words: a worse product)?

I like the sound and ideas of your plugins but with the competition being so tight in the plugin marketplace, for me it's the "packaging" that's keeping me from buying your products, not a grudge. I'm just hoping you might take this into consideration with future products.

[whyterabbyt]

For reference, the very high quality convolution plugin SIR2 is a single file sized 3,12 megs, the toneboosters timemachine DAC simulator is also a single file sized 2,75 - both completely portable.

For further reference, the Melda convolution plugin is 36Mb, and izotope Trash 2, which offers convolution and distortion, is 30Mb.

I like the sound and ideas of your plugins but with the competition being so tight in the plugin marketplace, for me it's the "packaging" that's keeping me from buying your products, not a "grudge" or anything like that. I'm just hoping you might take this into consideration with future products etc.

Just to balance this, I will continue to buy products on their capabilities, not whether or not their 'packaging' is larger or smaller than other vendors' products. In these days of 16Gb RAM/3Tb HD systems, I dont want plugin design to be compromised for the sake of something arbitrary like its on-disk footprint.

[samsam]

I guess I'm just sloppy and easy-going, 'cos apart from multi-GB stuff that's a concern because of my crappy internet, I have no idea how big plugin installers are., nor would I care, pretty much for reasons WR just laid out.

[Liero]

I guess I forgot to emphasize that size wasn't really my main issue here, in descending order of importance it is:

1) File dependency hell (one file gets moved for one reason or the other and everything stops working)
2) Files forced into multiple, different locations like vstplugins folder AND Program Files folder (not sure if chipcrusher does this)
3) Installers (I'd rather have a zip file, for people who know their computers and want to know which files go where this is faster and easier - just extract something into your plugin folder)
4) Registry entries (linked to dependency hell, since the registry is often the place a program checks for file locations)
5) File count concerns
6) File size concerns
....
999) Am I able to skin the plugin myself?

My 2c

Whyterabbyt: Of course I buy products mainly because of their capabilites. In a marketplace that has multiple contenders, however, it's quite possible that sound quality is on par with other products - after that it's stuff like packaging that's important.

[davidv@plogue]

Hello

This will be my last post on the subject.

chipsounds, chipcrusher and a bunch of other products past and future all share our ARIA Engine runtime, which allows us to create vastly different products in a modular fashion using a central registry for Licenses, UI generation, sub plugin management etc.

ARIA Products can interact, for instance ARIA Player can load chipsounds presets, chipsounds and chipcrusher share the convolution engine - for the PC Speaker, etc.

On top of sampling and synthesis, it NOW allows us and our OEMs the possibility to create straight effects products and hybrids, and chipcrusher is the first. Of course if chipcrusher were our sole product we would have done things very differently.

I understand this design is different than what you are used to but if you don't mess around with your system and just use the installers, then there is no problem. And even If by accident something gets moved, just re-run the installers. For many users (not all of which are folder/dll literate), this is by far the easiest support solution.

You prefer a straight DLL, fine, this product is not for you, I wont change the design I've been working on for 40 hours a week for 8 years just to please the 2% that just seem to care about how files are placed on the hard drive.

[whyterabbyt]

Hello

This will be my last post on the subject.

chipsounds, chipcrusher and a bunch of other products past and future all share our ARIA Engine runtime, which allows us to create vastly different products in a modular fashion using a central registry for Licenses, UI generation, sub plugin management etc.
Products interract and you can have presets made for products X show in product Y.
(ARIA Player can load chipsounds presets, chipsounds and chipcrusher share the convolution engine - for the PC Speaker - , etc)

On top of sampling and synthesis, it NOW allows us and our OEMs the possibility to create pure effects products, and chipcrusher is the first. Of course if chipcrusher was my sole product I would have done things differently.

I understand this design is different than what you are used to but if you don't mess around with your system and just use the installers, then there is no problem. And even If by accident something gets moved, just re-run the installers. For many users (not all of which are folder/dll literate), this is by far the easiest support solution.

You prefer a straight DLL, fine, this product is not for you, I wont change the design I've been working on for 40 hours a week for 8 years just to please the 2% that just seem to care about how files are placed on the hard drive.

And of course its not as though we dont have junction points and symbolic links, which is what sensible folk who want to rearrange and mess the hell of the the nice developers's intentions for their plugins in order to suit our own preferred arrangements without breaking anything can use.
I'll bet a pound to a penny that Im actually fussier about where stuff gets located than Liero says he is, except that I'm prepared to manage any nonstandard relocation stuff myself.

[ExtremeXS]

U-He and Camel Audio products spring to mind that also keep there files external to the core DLL plugin. So it's hardly a single developer doing things completely different.

I dont really see that as an issue for which software I do and don't purchase, but then I tend to buy things I want, rather than things to sell and later clean up.

[dayjob]

enjoying chipcrusher a lot. the installer is not something that crossed my mind. it works, it sounds good. end of story for me

[Liero]

Hello

This will be my last post on the subject.

chipsounds, chipcrusher and a bunch of other products past and future all share our ARIA Engine runtime, which allows us to create vastly different products in a modular fashion using a central registry for Licenses, UI generation, sub plugin management etc.

ARIA Products can interact, for instance ARIA Player can load chipsounds presets, chipsounds and chipcrusher share the convolution engine - for the PC Speaker, etc.

On top of sampling and synthesis, it NOW allows us and our OEMs the possibility to create straight effects products and hybrids, and chipcrusher is the first. Of course if chipcrusher were our sole product we would have done things very differently.

I understand this design is different than what you are used to but if you don't mess around with your system and just use the installers, then there is no problem. And even If by accident something gets moved, just re-run the installers. For many users (not all of which are folder/dll literate), this is by far the easiest support solution.

You prefer a straight DLL, fine, this product is not for you, I wont change the design I've been working on for 40 hours a week for 8 years just to please the 2% that just seem to care about how files are placed on the hard drive.

Fair enough, just voicing my opinion and raising awareness of the two-percenters, although I personally think it might be a few more.

[Liero]

U-He and Camel Audio products spring to mind that also keep there files external to the core DLL plugin. So it's hardly a single developer doing things completely different.

I dont really see that as an issue for which software I do and don't purchase, but then I tend to buy things I want, rather than things to sell and later clean up.

Urs Heckmann changed the way his plugins are installed a few years ago, nowadays you can move the plugin by just moving the entire folder with its contents. Nothing touched in the registry - very clean, very nice. Camel Audio stated on this forum not too long that Alchemy 2 is going to have a different, possibly installerless solution with less dependency hell and OS shenanigans. BTW all this because of user feedback and wishes.

[camsr]

I just like portable software and it's not like the .dll needs to use the registry if it's programmed not to.

EXAMPLE:
I just recently installed a large software suite on my computer, which is not portable software. Now my bootup time is TWICE AS LONG and some things ARE NOT WORKING LIKE THEY USED TO. Maybe I should just defrag, but IDK if that would help.

[camsr]

And of course its not as though we dont have junction points and symbolic links, which is what sensible folk who want to rearrange and mess the hell of the the nice developers's intentions for their plugins in order to suit our own preferred arrangements without breaking anything can use.

While this will solve the problem of a totalitarian installer, ask yourself if it's necessary.