DC12 is Here (August - December 2012)

[whyterabbyt]

In my opinion, this is a bit of a trite distinction.

trite
   [trahyt] Show IPA
adjective, trit·er, trit·est.
1.lacking in freshness or effectiveness because of constant use or excessive repetition; hackneyed; stale: the trite phrases in his letter.
2.characterized by hackneyed expressions, ideas, etc.: The commencement address was trite and endlessly long.
3.Archaic . rubbed or worn by use.

No, not seeing what you're actually talking about there. If you could point out where what Ive said has been 'excssively repeated' I'd be grateful, as I dont think I recall it being discussed very much at all at KVR.

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?

Well, if you want to argue with those 'valid justifications', go argue with Ben, it was his decision. Im merely trying to explain why Reaktor ensembles might constitute 'soundware.'

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.

Argue away. With Ben.

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.

Im familiar with how Synthmaker and Reaktor work, thanks. And other interpreters, compilers, and JIT compilers, in the audio realm and more generically. Its completely irrelevant to my point, though. I was highlighting an obvious technical difference Reaktor ensembles and natively-compiled plugins in order to posit an explanation for Ben's categorisation of Reaktor ensembles as 'soundware'. I dont really give a toss one way or the other as to whether you think Synthmaker-built plugins resemble Reaktor ensembles more than they resemble natively-compiled plugins or not; I have no horse in the race.

If you have a problem with Ben's distinction, take it to him. If you have a problem with me trying to explain what distinction he's making, feel free to provide an alternate explanation of his rationale. Or ask him.

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.

Who cares? I didnt make any such distinction. In fact I made no reference to Synthmaker whatsoever.

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.

Feel free to argue that too; I dont really care. It has nothing to do with anything I said.

[ghettosynth]

...

[whyterabbyt]

By this reasoning, all code is data that dictates what the CPU will do.

Except that native code is actually directly controlling what the processor does to its registers, and the memory locations some of those registers point to.

In the case of something like a Reaktor ensemble, some bit of native code is scanning a data structure which has been set up dependent on the contents of the ensemble file, then that native code is matching patterns in that data structure, and calling some other native code with arguments dependent on other bits of that data structure. The native code that then gets called is the bit that directly controls what the processor does to its registers, and the memory locations some of those registers point to.

The distinction between compiled code and interpreted code is pretty well established. If there's a grey area, its JIT compilation not 'binding' as you called it.

[jobromedia]

Excuse me, but aren't you guys overlooking the most important aspect here? It's not the tool the plugin / instrument / entry was created with that's important here. It is the developer behind the tools that makes all the difference! Hence the name Developer Challenge!

[ghettosynth]

...

[ghettosynth]

Excuse me, but aren't you guys overlooking the most important aspect here? It's not the tool the plugin / instrument / entry was created with that's important here. It is the developer behind the tools that makes all the difference! Hence the name Developer Challenge!

I'm not, that's precisely my point. The Reaktor dev and the Synthmaker dev who create a similar quality product put in a similar amount of work and skill. The only significant distinction between them is, as I said, the Synthmaker dev can use his tool to bind it to its execution environment whereas the reaktor developer must rely on his end user to complete that step.

[jobromedia]

True. But you also forget that Reaktor dev's has the access to a wider market since it's also Mac compatible. That's why my goal is to create:

1. VST version of my plugin.
2. Reaktor version of my plugin.

To gain more exposure that way.

[ghettosynth]

...

[whyterabbyt]

Ok, well, binding is a generic computer science term. If you've studied CS in any sort of depth it should be familiar to you.

I have, it is , and your useage doesnt actually quite fit any established useage properly. I did comprehend that you were trying to communicate, though, hence me actually accepting your use of 'binding' without argument, and the obvious nod to that.

But since it would now seem to be somewhat important to you that we discuss the meaning of binding, enough so that you would concentrate on the 'obvious nod', and make the implication that I might have done so out of ignorance, let's briefly focus on the road you want to go down.

In computer science, binding refers to the creation of a simple reference to something which is larger and more complicated and used frequently. For clarity, the term 'binding' is generally qualified to clarify what it is that's being bound, eg name binding.

http://www.wordiq.com/definition/Bindin ... science%29

Here's a more explicit example which enumerates the various normal qualified applications of the term.

Computing

Binding (or associating) an Internet socket to a local port number and IP address
Binding (or connecting) to a server in client-server computing
Data binding, the technique of connecting two data elements together
XML data binding, representing XML document data using objects and classes
UI data binding, linking a user interface element to an element of a domain model, such as a database field
Key binding, or keyboard shortcut, mapping specific key combinations to specific software functionality
Language binding, a library which provides an interface to functionality from of another library written in a different programming language
Name binding, in a programming language, the association of data (or code) with an identifier
Dynamic binding (computer science), name binding which is resolved at run-time rather than in advance

None of the usual qualified usages particularly relates to your useage. It actually reads more like you should have used the term linking. Or, if you're still focussed on Synthmaker, which, just like the Perl compiler I've been using for about 12 years, packages the source code, assets and libraries up into a single executable or dynamic-linked library with a self-bootstrapping version of the environment required to run that code, then possibly bundling. But Reaktor doesnt do that.

The only significant distinction between them is, as I said, the Synthmaker dev can use his tool to bind it to its execution environment whereas the reaktor developer must rely on his end user to complete that step.

Yup, I do indeed think bundling is the term I'd expect someone who studied CS in any sort of depth to use here, as per:

PerlApp

Now with cross-platform wrapping, use this sophisticated, easy-to-use tool for bundling Perl source code and modules into executables for distribution for any platform.

.

Can we get on now, because its not that interesting given that I'd acknowledged what you wanted to mean?

Clearly, the execution environment is the larger and bigger thing that is used frequently. I stated explicitly that each of the environments is a combination of compiled and interpreted code. That's simply a fact. There is far more similarity than differences between these environments which was my point to begin with. Both Core cells, and Synthmaker Code modules are compiled. That which is not compiled, is interpreted.
Your long-winded description of interpretation of source doesn't negate that fact.

Again, you're finding commonalities between oranges and satsumas, in response to me pointing out the differences between apples and oranges. Its quite irrelevant to what I wa saying.

There are no short-winded descriptions of source code compilation which are useful to a layman, Im afraid. And since I dont automatically assume that everyone else has studied compiler and interpreter design, you'll obviously understand why that longer description was provided. It wasnt intended to 'negate' anything, it was intended to describe the difference between several processes. Again, you seem to be under the impression that Im arguing for something.

And its still the fact that a Reaktor ensemble is provided as 'source', which is loaded into a native-code plugin then interpreted, and possibly JIT-compiled by that, rather than being pre-compiled, which may account for Ben's differentiating them from a native-code plugin. As I say, if you're concerned about his distinction, ask him.

Just because Reaktor is graphical, doesn't mean that it's not a language, and consequently, that ensembles are source code.

Again, not something I argued one way or the other. Still no horse.

[ghettosynth]

Ok, well, binding is a generic computer science term. If you've studied CS in any sort of depth it should be familiar to you.

I have, it is , and your useage doesnt actually quite fit any established useage properly.

In your experience, I'm sure. As I said, you're coming off as trite and pedantic, and not a little bit screechy. I used the term casually, something that's quite often done. The definition I shared with you, unlike the wikipedia page that you copied, really captures the essence of how the word is often used in casual conversation.

Seriously, arguing about which word best generically conveys the idea that the two development processes are more similar than they are different is the very essence of pedantry.

If you want to get pedantic, however, bundling is only appropriate in the sense of synthmaker, reaktor does not "bundle" the source with the execution environment, clearly, they are delivered separately. Neither is linking correct for the same reason. Both terms convey more specific ideas than binding which is a generic term that abstractly captures the essence of the processes that occur in both environments.

So we could say something like this:

The fundamental difference between the two development processes is really only that the SM dev is able to "bundle" his source with outsim's code thus "binding" the source to its execution enviroment. In contrast, the Reaktor dev must "distribute" his source since no "bundling" option is available to him thus relying on the user to handle the "binding" of his source to its execution environment at runtime.

Notice how binding is correct in both contexts, bundling is not. This is really just a generic application of the concepts of early and late binding.

Again, the essence of my point is as follows.

1) You referred to reaktor ensembles simply as data. This is simply incorrect. Reaktor ensembles are programs. I'm reasonably certain, in fact, that even without core, Reaktor is Turing complete.

2) Synthmaker devs do not do vastly different work to create their products than Reaktor devs. The processes are far more similar than they are different.

3) The fundamental difference is simply that the SM dev is able to mask the similarity and the Reaktor dev cannot.

[miedex]

Someone should split this thread before it scares off all the prospective participants.

[ghettosynth]

...

[ghettosynth]

...

[IrionDaRonin]

I see, my apologies, I misunderstood what you were saying. I agree, but perhaps it would be interesting to talk about what people think are the best of different categories and what things that they think are missing?

No, don't worry, no need to apologize. My english is not perfect yet and i miss some meanings of some words yet.
I said "High handicap", which i thought it means "High Level".
I'm a freebie lover very long time ago. So doubtly i would say bad things about freebies and indie developers. They brings us the fact of making music, for free. That's priceless.

So, my apologies.

Have a good day guys

[whyterabbyt]

In your experience, I'm sure. As I said, you're coming off as trite and pedantic, and not a little bit screechy.

Not quite as much as you were, though. Considering this is basially your interjection into an explanation I was making to someone else, you certainly have kept it going.

I used the term casually, something that's quite often done. The definition I shared with you, unlike the wikipedia page that you copied, really captures the essence of how the word is often used in casual conversation.

Of course it does; it must do because you say it does. I guess Ive just been really unlucky with my experience of those relevant casual conversations.

Seriously, arguing about which word best generically conveys the idea that the two development processes are more similar than they are different is the very essence of pedantry.

Which bit of 'I dont give a toss' was a problem for you? You went down the "if you'd studied CS you'd understand the term" route, and now its just 'casual' useage. Who would have expected anyone to actually make the distinctions that people who have studied CS would actually know after a statement like that?

Are you just pissed off because I did know the term, and its correct useage, and highlighted the actual terms you would have been better off using?

If so, that's a shame. I still dont give a toss.

If you want to get pedantic, however, bundling is only appropriate in the sense of synthmaker, reaktor does not "bundle" the source with the execution environment, clearly, they are delivered separately.

Here you go again telling me something I already knew, and as though I'd claimed otherwise. Thats getting, well, 'trite', really. As in 'frequently repeated.'

Synthmaker builds VSTs which are bundles, Reaktor doesnt. And voila, that's the likelye reason why Reaktor ensembles are being called soundware for the purpose of this event, but Synthmaker plugins arent.
If you actually bother to look, I started off by suggesting that Reaktor ensembles are probably being considered soundware because they were not self-contained.
And lo, Synthmaker-built plugins are self-contained, because they're bundles. Your 'the user has to bind the ensemble' translates to 'the user has to open Reaktor, and load the ensemble into it' which means (a) it isnt self-contained and (b) it isnt self-contained.

So we're where I came in, and nothing has changed. Ho hum.

Neither is linking correct for the same reason. Both terms convey more specific ideas than binding which is a generic term that abstractly captures the essence of the processes that occur in both environments.

So who claimed linking was correct?

So we could say something like this:

The fundamental difference between the two development processes is really only that the SM dev is able to "bundle" his source with outsim's code thus "binding" the source to its execution enviroment. In contrast, the Reaktor dev must "distribute" his source since no "bundling" option is available to him thus relying on the user to handle the "binding" of his source to its execution environment at runtime.

Notice how binding is correct in both contexts, bundling is not.

Except 'binding' is pretty forced in both contexts, and probably innacurate in the latter. Try 'packaging with' and 'handle the loading of his source into' for a far better explanation.

Basically you're rely on shoehorning 'loading into' and 'packaging with' into 'binding' just so you can claim that since both do 'binding,' then 'loading into' and 'packaging' are the same thing.

And you're still focussing on this conflated notion of 'binding' to underpin your argument that X is like Y. Yet all along the actual thing being discussed was why X isnt like A. And all along bundling is the reason X is not like Y but is like A.

This is really just a generic application of the concepts of early and late binding.

Early and late binding of what?
And which applies where, and makes your argument for you?

Is there a website you can point me to which has a 'casual definition' which includes some sort of reference to 'the user has to manually load in some source code?'

Again, the essence of my point is as follows.
1) You referred to reaktor ensembles simply as data. This is simply incorrect. Reaktor ensembles are programs. I'm reasonably certain, in fact, that even without core, Reaktor is Turing complete.

2) Synthmaker devs do not do vastly different work to create their products than Reaktor devs. The processes are far more similar than they are different.

3) The fundamental difference is simply that the SM dev is able to mask the similarity and the Reaktor dev cannot.

Are you trying to claim that, say, source code isnt data? Do you have some 'casual' meaning for data too?
In this context, lets be clear that Reaktor ensembles are probably some sort of representation of the state of the execution graph, a 'source code' for the instantiation and connection of the objects. But they are not compiled programs. Lets have no fuzziness over conflating 'programs' with 'source code' and 'executable code' in order to prove that source code and executable code are the same, please.

If you wish to take these 3 points to Ben, and argue your case, feel free. I really dont give a toss, and I have no idea why you're, well, erm, somewhat tritely and pedantically going over it again and again with me. But I really dont think 'Reaktor is Turing complete' is a final swaying argument.
At the end of the day, and as I said at the beginning, Reaktor ensembles aren't self-contained. That's probably the deciding factor.