[Sc-devel] Embedding Specs in SynthDefs

[Scott Wilson]

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

>
>>
>> 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.
>
> So it would be better for them to use Instrument (as I propose it, a
> superclass of Instr), right ?  then no need to decompile those synth
> defs.

I see no reason they shouldn't support Instrument as well. But  
patterns aren't generally dependant on specs, at least not at the  
moment, or?

This might be suggestive of some new possibilities though...
>
> and curiously, that is in fact where Instrument originally came from.
>
> so we should simply put it back.
>
> the problem I had with jmc's Instrument was that it was coupled with a
> specific GUI system.
>
> but here we would have just a synth def holder.  GUI systems can do
> whatever they want (by reading the specs), and so can patterns.

Since you're keen on sharing, I like the idea of having an optional  
GUI which can be added to one's Instrument and distributed with it. I  
agree that guiBody should probably go, but we could provide a generic  
hook for this. If a GUI is not supplied, we could still have it  
generate a simple default one along the lines of  
SynthDesc:makeWindow. This would be useful at least for testing  
purposes.
>
>> Um, patterns. Or are you proposing they start using Instr?
>
> Instrument
>
> just like it used to be
> see its still there :
>
> 			event[\instrument] = synthName;
>
> no reason to break anything though.  look it up in SynthDescLib, if
> not found then look it up in Instrument, loading from file if need be.
>  this would be quite ideal.

This seems sensible.
>
> Instr would then be interchangeable, a subclass that allows objects to
> be passed in and an Out.ar to be tacked on when needed.

Okay, I can see that given that this is going to be added into  
Common, the difference between my slightly expanded SynthDesc and  
Instrument is pretty fine grained, and since the idea of altering the  
scsyndef file format is getting no love (with the exception or  
Gerard...) I'll drop it.

I still think it would be useful to have the scsyndef file and  
Instrument stored together in one convenient package though, at least  
optionally. Maybe when an Instrument is written to disk it could  
optionally have the scsyndef written at the same time, both into a  
subfolder of the Instrument dir. Then you could ask the server to  
load that dir, and you could have the choice of just the server-side,  
just the client-side, or both.

It's funny how we circle around ideas and assumptions that persist  
from earlier in the development of SC, sometimes pulling away,  
sometimes coming back. From the early days of SC3 it seemed to me  
that the idea of having defs pre-compiled was encouraged. It's been  
interesting to see how the assumption that one is doing that has  
caused some issues. I've sometimes wonder if it makes sense, even  
though I benefit from it. (I have some pieces which use thousands of  
pre-compiled defs. Waiting for them to load is bad enough, I would  
hate to wait for them to be re-compiled...)

S.