[Sc-devel] Embedding Specs in SynthDefs

Scott Wilson sdwilson at wesleyan.edu
Mon Jul 30 18:53:20 PDT 2007


On 30 Jul 2007, at 17:30, felix wrote:

> On 7/30/07, Scott Wilson <sdwilson at wesleyan.edu> wrote:
>> 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.
>
> Instruments are not written to disk.  they are source code.
>
> it is exactly the same as with SynthDef("name",{ })
>
> the advantage is that you can save your Instruments to a directory and
> thus always know where to find the source code file.

I know what they are. When you 'save them to a directory' you are  
'writing them to disk'. I'm not sure what you imagine I meant.

> you could check
> file mtimes and recompile any whose instrument files have changed.

If you save the def in the same place then you 'will always know  
where to find' the compiled def to check if it's changed.

>
>>
>> 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...)
>
> computers are very fast these days.
>
> I always honor the maxim that "Programmer time is more important than
> Computer time".

Well in the pieces I mentioned above it would be 3 or 4 minutes to  
recompile them even on a fast machine. I don't see how that saves any  
time for the computer or the programmer. :-)

S. 



More information about the Sc-devel mailing list