DC12 is Here (August - December 2012)

[VitaminD]

Perhaps the dates could be extended by a month...

As for a dedicated Reaktor category, I think that should fall into soundware.

Please reconsider (for next time I suppose) as Reaktor isn't soundware. Synth presets are soundware. Reaktor is a full modular environment where one developes synthesizers and effects. It's a different animal than just programming simple sounds.

Its not self-contained, though. I guess that's what Ben ultimately means by 'soundware.'

ah

but.. Self-contained.. what does that mean?

[stanlea]

That means that you need Reaktor to use an ensemble built with Reaktor.

[VitaminD]

you need a VST host to use a VST though ???

just because VST hosts are more available than reaktor hosts doesn't make it any more or less contained..


In any case.. Reaktor category next year pretty please with sugar lumps on top.. even if its a lump sum category for instruments and effects..

[whyterabbyt]

ah

but.. Self-contained.. what does that mean?

a standalone will process or generate audio or MIDI on its own, and manage outputting that as audio or midi. but as far as processing or generating audio goes, its the standalone that does it; its self-contained.

a plugin will will process or generate audio or MIDI on its own, but sends that audio or midi to a host. but as far as processing or generating audio goes, its the plugin that does it; its self-contained.

a Reaktor ensemble or Kontakt patch doesnt do anything. its data to dictate what something else will do. so as far as processing or generating audio goes, its Reaktor or Kontakt that does it, and the ensemble or patch is data that dictates what Reaktor or Kontakt does. its not self-contained.

[highkoo]

i'd be up for a collaboration with a coder if its allowed. I do GUI's, most recently the new Mausynth one.

Hey!
Someone take him up on this!
Good stuff on Mausynth!


Oh and,

[VitaminD]

ah

but.. Self-contained.. what does that mean?

a standalone will process or generate audio or MIDI on its own, and manage outputting that as audio or midi. but as far as processing or generating audio goes, its the standalone that does it; its self-contained.

a plugin will will process or generate audio or MIDI on its own, but sends that audio or midi to a host. but as far as processing or generating audio goes, its the plugin that does it; its self-contained.

a Reaktor ensemble or Kontakt patch doesnt do anything. its data to dictate what something else will do. so as far as processing or generating audio goes, its Reaktor or Kontakt that does it, and the ensemble or patch is data that dictates what Reaktor or Kontakt does. its not self-contained.

Oh I see.. But isn't what a coded VST does too? The only major difference is a VST is compiled and a Reaktor ENS is not.

The end result, however, requires another piece of software though for either system -- one cannot execute a Reaktor ens on it's own anymore than one can execute a VST (dll) on it's own.

[jobromedia]

Well then add a modular category. It's just 3 days into the contest, so no problem the way I see it.

[IrionDaRonin]

I'm glad there is a DC12 at last!
For first time in my life i will see this event running.

You can do nice stuff!
Now freeware synths and effects are in a high handicap. I hope you can go beyond that.

We could use some nice synths in OSC someday.

Good luck, guys

[ghettosynth]

...

[VitaminD]

I'm glad there is a DC12 at last!
For first time in my life i will see this event running.

You can do nice stuff!
Now freeware synths and effects are in a high handicap. I hope you can go beyond that.

We could use some nice synths in OSC someday.

Good luck, guys

oh yeah.. hoping some of the big names come out as well as the lone wolves..

[ghettosynth]

...

[whyterabbyt]

ah

but.. Self-contained.. what does that mean?

a standalone will process or generate audio or MIDI on its own, and manage outputting that as audio or midi. but as far as processing or generating audio goes, its the standalone that does it; its self-contained.

a plugin will will process or generate audio or MIDI on its own, but sends that audio or midi to a host. but as far as processing or generating audio goes, its the plugin that does it; its self-contained.

a Reaktor ensemble or Kontakt patch doesnt do anything. its data to dictate what something else will do. so as far as processing or generating audio goes, its Reaktor or Kontakt that does it, and the ensemble or patch is data that dictates what Reaktor or Kontakt does. its not self-contained.

Oh I see.. But isn't what a coded VST does too? The only major difference is a VST is compiled and a Reaktor ENS is not.

See highlighting. A VST is a dynamically-loaded library; code which operates at the same level of operation as the host. When a VST plugin is in use, the host passes the data to the plugin, which processes it and passes the processed version back. The VST is the code which carries out the processing.
When a Reaktor ensemble is in use, the host passes data to Reaktor. Reaktor then processes the audio, according to a set of instructions which tell it (Reaktor) what sequence of operations to perform. Reaktor contains the code which carries out the processing.

The end result, however, requires another piece of software though for either system -- one cannot execute a Reaktor ens on it's own anymore than one can execute a VST (dll) on it's own.

However, the VST is a code library contains all the functionality necessary to generate or process audio. It wont operate on its own because it doesnt contain any code which knows when to operate, where to get data from, or what to do with data its processed (all of which are the hosts' job) but it does contain the code that does the work.
A Reaktor ensemble, just like a synth preset, or a kontakt patch, doesnt contain any code that does the work, its a set of instructions and values used by the thing that does the work.

Think of it like a restaraunt. The customer wants a particular dish. The restaraunt is like your host, it provides the infrastructure to cook and serve food.
The chef is the plugin; the restaurant tasks a chef to process ingredients and create the dish. Imagine some chefs know already know how to make the dishes they're tasked with, but only those dishes. But some chefs can make any dish, but only if they have appropriate instructions. The ensemble is the recipe. Its a list of instructions to the chef... but the recipe doesnt chop food up, mix it and heat it etc. The chef does, according to the recipe.

Does that help make it clearer?

[jobromedia]

Very convincing! I might borrow that analogy when I describe the concept of plugins to people with less knowledge.

[IrionDaRonin]

Could I ask you to try to discuss and, perhaps identify, what some of the biggest challenges are, in your opinion, of course?

What kinds of limitations lead to strong words like "high handicap" ?

We could use some nice synths in OSC someday.

To be clear, I don't mean at all to challenge your opinion, rather, I'm genuinely interested in what talented end users (I've heard your submissions), feel is lacking?

Hi, what you mean exactly?
What do you want to know excatly, i will be pleased to answer any question from you.

Anyway, what i said in my post before, it was about that the nowadays freebies are so great, nothing to envy to commercial stuff.
So minimum, DC12 entries should be at least as good as the actual freebies in quality, or even better (to go beyond of this quality)
I basically meant that.

About lacking? which lack you mean?
Personally, i'm not thinking there is a lack of anything from freebies nowadays. They are great, low on CPU, nice GUIs, great results.
Take as example Full Bucket Music Deputy MK2. There is no lack in that one. So i would like to see entries with this level, at least.

New types of synthesis, glitchy effects like Turnado, a preset morpher, etc. Would be nice stuff.

And sorry of using "High Handicap". I thought it was mean "High level", or a high bar to be reachable.
My bad english with some words. Sorry.

Have a good day, Ghettosynth.

[ghettosynth]

ah

but.. Self-contained.. what does that mean?

a standalone will process or generate audio or MIDI on its own, and manage outputting that as audio or midi. but as far as processing or generating audio goes, its the standalone that does it; its self-contained.

a plugin will will process or generate audio or MIDI on its own, but sends that audio or midi to a host. but as far as processing or generating audio goes, its the plugin that does it; its self-contained.

a Reaktor ensemble or Kontakt patch doesnt do anything. its data to dictate what something else will do. so as far as processing or generating audio goes, its Reaktor or Kontakt that does it, and the ensemble or patch is data that dictates what Reaktor or Kontakt does. its not self-contained.

Oh I see.. But isn't what a coded VST does too? The only major difference is a VST is compiled and a Reaktor ENS is not.

See highlighting. A VST is a dynamically-loaded library; code which operates at the same level of operation as the host. When a VST plugin is in use, the host passes the data to the plugin, which processes it and passes the processed version back. The VST is the code which carries out the processing.
When a Reaktor ensemble is in use, the host passes data to Reaktor. Reaktor then processes the audio, according to a set of instructions which tell it (Reaktor) what sequence of operations to perform. Reaktor contains the code which carries out the processing.

The end result, however, requires another piece of software though for either system -- one cannot execute a Reaktor ens on it's own anymore than one can execute a VST (dll) on it's own.

However, the VST is a code library contains all the functionality necessary to generate or process audio. It wont operate on its own because it doesnt contain any code which knows when to operate, where to get data from, or what to do with data its processed (all of which are the hosts' job) but it does contain the code that does the work.
A Reaktor ensemble, just like a synth preset, or a kontakt patch, doesnt contain any code that does the work, its a set of instructions and values used by the thing that does the work.

Think of it like a restaraunt. The customer wants a particular dish. The restaraunt is like your host, it provides the infrastructure to cook and serve food.
The chef is the plugin; the restaurant tasks a chef to process ingredients and create the dish. Imagine some chefs know already know how to make the dishes they're tasked with, but only those dishes. But some chefs can make any dish, but only if they have appropriate instructions. The ensemble is the recipe. Its a list of instructions to the chef... but the recipe doesnt chop food up, mix it and heat it etc. The chef does, according to the recipe.

Does that help make it clearer?

In my opinion, this is a bit of a trite distinction. Surely the more valid justification for not allowing them in the challenge is simply that a Reaktor ensemble is something that is explicitly linked to an expensive third party product?

I would argue that the biggest problem with allowing Reaktor devs is that it complicates the voting. The only way that you could do it practically is to treat it as a completely separate category.

If we were to observe equally talented Synthmaker and Reaktor devs work on a release, we would largely observe them producing similar work. There are differences, of course, but in the end, the actual work produced by each developer is NOT stand alone. The Synthmaker dev is able to use his tool to write the combination of his efforts, and Outsim's efforts to a single standalone file, whereas the Reaktor dev distributes his work as source.

In neither case could it be argued that one process is distinctly different from the other from the developer's point of view, nor, in fact, at runtime. Both environments are a combination of compilation and interpretation. The generation of a VST from SM is NOT a pure compilation process, it's merely a bundling. It's well documented that the distributed VSTs contain the original schematics which are loaded and executed at runtime.

To distinguish one as data and the other as code isn't, in fact, correct. In both cases the developer's output is largely a representation of code that is partially compiled and partially interpreted.

In fact, it could be argued that really, the only difference is that the Synthmaker dev binds his code to its execution environment whereas the Reaktor user handles the binding of code to its execution environment.