[Sc-devel] Embedding Specs in SynthDefs

[Scott Wilson]

On 30 Jul 2007, at 00:11, felix wrote:

> On 7/29/07, Scott Wilson <sdwilson at wesleyan.edu> wrote:
>> I think 'totally' is a little strong, but I acknowledge it would be a
>> change.
>
> well yes, it is a total change.  it changes from a
> decompiling/analysis class that parses the scsynth def files into a
> class that creates synth defs and holds information about the intended
> input specs.  that's a completely different usage.

I don't know why you keep thinking I'm proposing that. I don't need  
to create defs from a SynthDesc. That does sound like Instr.

>
> those things are meant to be a compacted fast loadable format for the
> server and nothing more.

Well, not only. Patterns depend on them client-side. The whole  
SynthDesc situation came about because of the need to decompile those  
files back into the client. There was a choice made to do that rather  
than store the code in a client friendly format, or to store it in  
both (which would cause sync problems). I'm not saying it's ideal but  
that's the case.


>   it would slow down the server to put these
> extra bits in.

As I stated in an earlier message, that's not really true, at least  
in any significant way, since they would be optional. In cases where  
they are included we're talking about a pretty small extra amount of  
data to load. Parsing in any case would be as fast, and SynthDef:send  
would not send specs.

> its just not supposed to be there, IMO.

I understand the feeling.
>
> also you are throwing away so much.  with an Instrument/Instr you can
> load it up and see the comments in the code and all the original
> formatting.

Well, I'm not saying there aren't cases where that's needed, I'm just  
saying there are many cases where that's not. This wouldn't need to  
be either/or, as I've stated several times.

I have my code. If I want to look at that I can. The advantages you  
describe are mostly for efficient sharing of code with other people. Or?
>>
>> That still doesn't address the storage proposal. You could derive
>> Instrs from scsyndef files if they were extended in the way I've
>> proposed, oder?
>
> you could occasionally do it but there isn't much point.
> an Instr is more fluid then a synth def.

No argument there.

> I can see no reason whatsoever to want to read an scsyndef file.

Um, patterns. Or are you proposing they start using Instr?

S.