[Sc-devel] Adding specs to synthdefs?

[James Harkins-2]

I wonder if it would be useful to save control specs along with synthdefs, so that SynthDesc:makeWindow would have a better idea for slider ranges than simply using the control name to look up the spec? You might also want to override the default spec for a control name for a particular synthdef -- currently not possible with makeWindow.

It shouldn't be hard to write a set of specs into the file. I suppose scsynth would have to be adjusted to ignore them.

Potential problems I can think of off the top of my head --

- array arguments

- controls created explicitly in the body of the synthdef (rather than inferred from function arguments)

Maybe a dictionary of specs for that synthdef? That way, it wouldn't matter if the input is a function argument or not. E.g.,

SynthDef(\blurp, { |freq, gate, amp|

...

}, specs: (gate: #[0, 1, \lin, 1, 1]));

Just a thought, maybe not worth the effort.

hjh

: H. James Harkins

: jamshark70@...

: http://www.dewdrop-world.net

.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal."  -- Whitman

_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

[Dan Stowell]

This is something that comes up from time to time - I agree it would
be helpful to have some kind of spec data written, for various
reasons. It would be very helpful for people using non-sclang
approaches to communicating with scsynth, for example.

When you wrote "save control specs along with synthdefs", my first
thought was of a SEPARATE file containing the spec data (e.g. an ASCII
file called *.scspec). Would that be reasonable? It would have the
benefit of making no changes to scsynth or to the .scsyndef format.

I was working on some scplug stuff and thinking: "I wish I could
access the synth specs from Javascript". With ascii spec data I could
do that :)

If wanted, we could make it a switchable option - to save time/space,
users could opt not to generate these spec files.

Dan


2008/7/9 James Harkins <jamshark70@...>:

> I wonder if it would be useful to save control specs along with synthdefs,
> so that SynthDesc:makeWindow would have a better idea for slider ranges than
> simply using the control name to look up the spec? You might also want to
> override the default spec for a control name for a particular synthdef --
> currently not possible with makeWindow.
> It shouldn't be hard to write a set of specs into the file. I suppose
> scsynth would have to be adjusted to ignore them.
> Potential problems I can think of off the top of my head --
> - array arguments
> - controls created explicitly in the body of the synthdef (rather than
> inferred from function arguments)
> Maybe a dictionary of specs for that synthdef? That way, it wouldn't matter
> if the input is a function argument or not. E.g.,
> SynthDef(\blurp, { |freq, gate, amp|
> ...
> }, specs: (gate: #[0, 1, \lin, 1, 1]));
> Just a thought, maybe not worth the effort.
> hjh
>
> : H. James Harkins
>
> : jamshark70@...
>
> : http://www.dewdrop-world.net
>
> .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:
>
> "Come said the Muse,
>
> Sing me a song no poet has yet chanted,
>
> Sing me the universal."  -- Whitman
>
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>
>

--
http://www.mcld.co.uk

_______________________________________________
sc-dev mailing list

info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

[Josh Parmenter]

The separate file idea makes sense. Perhaps the file should actually  
contain everything that is needed for SynthDesc:makeWindow?

Josh

On Jul 9, 2008, at 6:03 AM, Dan Stowell wrote:

> This is something that comes up from time to time - I agree it would
> be helpful to have some kind of spec data written, for various
> reasons. It would be very helpful for people using non-sclang
> approaches to communicating with scsynth, for example.
>
> When you wrote "save control specs along with synthdefs", my first
> thought was of a SEPARATE file containing the spec data (e.g. an ASCII
> file called *.scspec). Would that be reasonable? It would have the
> benefit of making no changes to scsynth or to the .scsyndef format.
>
> I was working on some scplug stuff and thinking: "I wish I could
> access the synth specs from Javascript". With ascii spec data I could
> do that :)
>
> If wanted, we could make it a switchable option - to save time/space,
> users could opt not to generate these spec files.
>
> Dan
>
>
> 2008/7/9 James Harkins <jamshark70@...>:
>> I wonder if it would be useful to save control specs along with  
>> synthdefs,
>> so that SynthDesc:makeWindow would have a better idea for slider  
>> ranges than
>> simply using the control name to look up the spec? You might also  
>> want to
>> override the default spec for a control name for a particular  
>> synthdef --
>> currently not possible with makeWindow.
>> It shouldn't be hard to write a set of specs into the file. I suppose
>> scsynth would have to be adjusted to ignore them.
>> Potential problems I can think of off the top of my head --
>> - array arguments
>> - controls created explicitly in the body of the synthdef (rather  
>> than
>> inferred from function arguments)
>> Maybe a dictionary of specs for that synthdef? That way, it  
>> wouldn't matter
>> if the input is a function argument or not. E.g.,
>> SynthDef(\blurp, { |freq, gate, amp|
>> ...
>> }, specs: (gate: #[0, 1, \lin, 1, 1]));
>> Just a thought, maybe not worth the effort.
>> hjh
>>
>> : H. James Harkins
>>
>> : jamshark70@...
>>
>> : http://www.dewdrop-world.net
>>
>> .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:
>>
>> "Come said the Muse,
>>
>> Sing me a song no poet has yet chanted,
>>
>> Sing me the universal."  -- Whitman
>>
>> _______________________________________________
>> Sc-devel mailing list
>> Sc-devel@...
>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>>
>>
>
>
>
> --
> http://www.mcld.co.uk
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/


_______________________________________________
sc-dev mailing list

info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

[James Harkins-2]

A separate file is a great idea, and something I could easily
implement (when I have time).

On Wed, Jul 9, 2008 at 9:03 AM, Dan Stowell <danstowell@...> wrote:
> If wanted, we could make it a switchable option - to save time/space,
> users could opt not to generate these spec files.

One quick and easy way is - if you use .load(s), don't generate the
spec file, but if you use .store, do write it. (.memStore would save
the specs in the SynthDesc locally -- since it doesn't write a
.scsyndef file, it shouldn't write a spec file either.)

Josh --> "The separate file idea makes sense. Perhaps the file should
actually contain everything that is needed for SynthDesc:makeWindow?"

Kind of a GUI skin as well... so an extensible data structure would be useful.

hjh


--
James Harkins /// dewdrop world
jamshark70@...
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman

_______________________________________________
sc-dev mailing list

info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

[felix-38]

i would suggest using json format. compact, other languages love it.  human readable.

in fact ajax driven browser code would love it in case the lang wants to reply to a browser with what the specs are.  you can turn it into a javascript object and work with it right away.

On Wed, Jul 9, 2008 at 4:31 PM, James Harkins <jamshark70@...> wrote:

A separate file is a great idea, and something I could easily
implement (when I have time).

On Wed, Jul 9, 2008 at 9:03 AM, Dan Stowell <danstowell@...> wrote:
> If wanted, we could make it a switchable option - to save time/space,
> users could opt not to generate these spec files.

One quick and easy way is - if you use .load(s), don't generate the
spec file, but if you use .store, do write it. (.memStore would save
the specs in the SynthDesc locally -- since it doesn't write a
.scsyndef file, it shouldn't write a spec file either.)

Josh --> "The separate file idea makes sense. Perhaps the file should

actually contain everything that is needed for SynthDesc:makeWindow?"

Kind of a GUI skin as well... so an extensible data structure would be useful.

hjh


--
James Harkins /// dewdrop world

jamshark70@...
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman

_______________________________________________

sc-dev mailing list

info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

[stefan kersten-2]

On 09.07.2008, at 15:03, Dan Stowell wrote:

> This is something that comes up from time to time - I agree it would
> be helpful to have some kind of spec data written, for various
> reasons. It would be very helpful for people using non-sclang
> approaches to communicating with scsynth, for example.
>
> When you wrote "save control specs along with synthdefs", my first
> thought was of a SEPARATE file containing the spec data (e.g. an ASCII
> file called *.scspec). Would that be reasonable? It would have the
> benefit of making no changes to scsynth or to the .scsyndef format.
>
> I was working on some scplug stuff and thinking: "I wish I could
> access the synth specs from Javascript". With ascii spec data I could
> do that :)
>
> If wanted, we could make it a switchable option - to save time/space,
> users could opt not to generate these spec files.

intuitively i'd argue for adding the spec fields to the synthdef  
directly.
there'd be only one file to move around or delete and things cannot  
get out of
sync; imagine a synthdef written without a spec file while an older  
file still
exists.

currently a synthdef file looks like this (from the documentation):

int32 - four byte file type id containing the ASCII characters: "SCgf"
int32 - file version, currently zero.
int16 - number of synth definitions in this file (D).
[synth-definition] * D

so it'd be straightforward to bump the version number and add a metadata
section before the synth definitions (not backwards compatible). the  
reason
for not adding it after the synthdefs is that they cannot be skipped  
easily
because the section size is unknown; each synthdef would have to be  
parsed
before. so the new format could look like this:

int32 - four byte file type id containing the ASCII characters: "SCgf"
int32 - file version, currently zero.
int32 - metadata section bytes (M)
[ metadata byte ] * B
int16 - number of synth definitions in this file (D).
[synth-definition] * D

as to the metadata format, i think that json (as suggested by felix)  
is a good
idea. in javascript e.g. you would just skip the first 8 bytes, read  
the next
n bytes and interpret the string.

maybe we should also review another suggestion that has been made in  
the past:
string arguments to ugens. for static strings at least the following  
could
work:

* each synthdef contains a symbol table that is read from the file  
and stored
   in the server object
* string arguments to ugens are compiled as an index and the  
corresponding
   string is added to the symbol table
* ugens can then query symbol table strings by index

the format could be:

int32 symbol table section bytes
string1\0
string2\0
...

that's pretty much how csound does it i think, but it doesn't allow  
setting
argument strings dynamically.

thoughts?

<sk>


_______________________________________________
sc-dev mailing list

info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

[ronald kuivila]

Hi all,

   It can be useful to reuse a synthdef with different range  
constraints on its controls. So controlspecs could naturally be part  
of an expansion of the role of variants.  The variant would have the  
controlspecs, but might evolve to have a bunch of other stuff  
(preferred GUI, connection specifications in the manner of cruxxial,  
etc).

   The separate file approach reflects the reality that the specs  
being provided are irrelevant to the server.  This might be
better in the long term as it keeps the server insulated from any  
added complexity.  But it is certainly true that an integrated file  
simplified bookkeeping.

RJK



On Jul 9, 2008, at 12:44 PM, stefan kersten wrote:

> On 09.07.2008, at 15:03, Dan Stowell wrote:
>> This is something that comes up from time to time - I agree it would
>> be helpful to have some kind of spec data written, for various
>> reasons. It would be very helpful for people using non-sclang
>> approaches to communicating with scsynth, for example.
>>
>> When you wrote "save control specs along with synthdefs", my first
>> thought was of a SEPARATE file containing the spec data (e.g. an  
>> ASCII
>> file called *.scspec). Would that be reasonable? It would have the
>> benefit of making no changes to scsynth or to the .scsyndef format.
>>
>> I was working on some scplug stuff and thinking: "I wish I could
>> access the synth specs from Javascript". With ascii spec data I could
>> do that :)
>>
>> If wanted, we could make it a switchable option - to save time/space,
>> users could opt not to generate these spec files.
>
> intuitively i'd argue for adding the spec fields to the synthdef  
> directly.
> there'd be only one file to move around or delete and things cannot  
> get out of
> sync; imagine a synthdef written without a spec file while an older  
> file still
> exists.
>
> currently a synthdef file looks like this (from the documentation):
>
> int32 - four byte file type id containing the ASCII characters: "SCgf"
> int32 - file version, currently zero.
> int16 - number of synth definitions in this file (D).
> [synth-definition] * D
>
> so it'd be straightforward to bump the version number and add a  
> metadata
> section before the synth definitions (not backwards compatible).  
> the reason
> for not adding it after the synthdefs is that they cannot be  
> skipped easily
> because the section size is unknown; each synthdef would have to be  
> parsed
> before. so the new format could look like this:
>
> int32 - four byte file type id containing the ASCII characters: "SCgf"
> int32 - file version, currently zero.
> int32 - metadata section bytes (M)
> [ metadata byte ] * B
> int16 - number of synth definitions in this file (D).
> [synth-definition] * D
>
> as to the metadata format, i think that json (as suggested by  
> felix) is a good
> idea. in javascript e.g. you would just skip the first 8 bytes,  
> read the next
> n bytes and interpret the string.
>
> maybe we should also review another suggestion that has been made  
> in the past:
> string arguments to ugens. for static strings at least the  
> following could
> work:
>
> * each synthdef contains a symbol table that is read from the file  
> and stored
>   in the server object
> * string arguments to ugens are compiled as an index and the  
> corresponding
>   string is added to the symbol table
> * ugens can then query symbol table strings by index
>
> the format could be:
>
> int32 symbol table section bytes
> string1\0
> string2\0
> ...
>
> that's pretty much how csound does it i think, but it doesn't allow  
> setting
> argument strings dynamically.
>
> thoughts?
>
> <sk>
>
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/ 
> MusicTechnology/880
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>

_______________________________________________
sc-dev mailing list

info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

[Scott Wilson-3]

It seems to me that maybe the def should be associated with the other  
data, rather than the other way around as we've been discussing.

Perhaps there should be a scsynthdesc file format (or something like  
it) which would contain all the data in a SynthDesc plus specs, a  
default GUI (or enough info to generate one), etc. This could contain  
the synthdef itself, and the server could be adjusted to extract it if  
need be. (Or maybe this could be a bundle of some sort which the  
server will read). This would keep the server specific info separate  
while allowing the other stuff to be conveniently packaged. Normal  
synthdefs files would still work and remain lightweight, so this new  
format could be optional.

You could associate specs, GUIs, whatever with variants if desired, or  
have global ones.

S.


On 12 Jul 2008, at 13:16, ronald kuivila wrote:

> Hi all,
>
>  It can be useful to reuse a synthdef with different range  
> constraints on its controls. So controlspecs could naturally be part  
> of an expansion of the role of variants.  The variant would have the  
> controlspecs, but might evolve to have a bunch of other stuff  
> (preferred GUI, connection specifications in the manner of cruxxial,  
> etc).
>
>  The separate file approach reflects the reality that the specs  
> being provided are irrelevant to the server.  This might be
> better in the long term as it keeps the server insulated from any  
> added complexity.  But it is certainly true that an integrated file  
> simplified bookkeeping.
>
> RJK
>
>
>
> On Jul 9, 2008, at 12:44 PM, stefan kersten wrote:
>
>> On 09.07.2008, at 15:03, Dan Stowell wrote:
>>> This is something that comes up from time to time - I agree it would
>>> be helpful to have some kind of spec data written, for various
>>> reasons. It would be very helpful for people using non-sclang
>>> approaches to communicating with scsynth, for example.
>>>
>>> When you wrote "save control specs along with synthdefs", my first
>>> thought was of a SEPARATE file containing the spec data (e.g. an  
>>> ASCII
>>> file called *.scspec). Would that be reasonable? It would have the
>>> benefit of making no changes to scsynth or to the .scsyndef format.
>>>
>>> I was working on some scplug stuff and thinking: "I wish I could
>>> access the synth specs from Javascript". With ascii spec data I  
>>> could
>>> do that :)
>>>
>>> If wanted, we could make it a switchable option - to save time/
>>> space,
>>> users could opt not to generate these spec files.
>>
>> intuitively i'd argue for adding the spec fields to the synthdef  
>> directly.
>> there'd be only one file to move around or delete and things cannot  
>> get out of
>> sync; imagine a synthdef written without a spec file while an older  
>> file still
>> exists.
>>
>> currently a synthdef file looks like this (from the documentation):
>>
>> int32 - four byte file type id containing the ASCII characters:  
>> "SCgf"
>> int32 - file version, currently zero.
>> int16 - number of synth definitions in this file (D).
>> [synth-definition] * D
>>
>> so it'd be straightforward to bump the version number and add a  
>> metadata
>> section before the synth definitions (not backwards compatible).  
>> the reason
>> for not adding it after the synthdefs is that they cannot be  
>> skipped easily
>> because the section size is unknown; each synthdef would have to be  
>> parsed
>> before. so the new format could look like this:
>>
>> int32 - four byte file type id containing the ASCII characters:  
>> "SCgf"
>> int32 - file version, currently zero.
>> int32 - metadata section bytes (M)
>> [ metadata byte ] * B
>> int16 - number of synth definitions in this file (D).
>> [synth-definition] * D
>>
>> as to the metadata format, i think that json (as suggested by  
>> felix) is a good
>> idea. in javascript e.g. you would just skip the first 8 bytes,  
>> read the next
>> n bytes and interpret the string.
>>
>> maybe we should also review another suggestion that has been made  
>> in the past:
>> string arguments to ugens. for static strings at least the  
>> following could
>> work:
>>
>> * each synthdef contains a symbol table that is read from the file  
>> and stored
>>  in the server object
>> * string arguments to ugens are compiled as an index and the  
>> corresponding
>>  string is added to the symbol table
>> * ugens can then query symbol table strings by index
>>
>> the format could be:
>>
>> int32 symbol table section bytes
>> string1\0
>> string2\0
>> ...
>>
>> that's pretty much how csound does it i think, but it doesn't allow  
>> setting
>> argument strings dynamically.
>>
>> thoughts?
>>
>> <sk>
>>
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

_______________________________________________
sc-dev mailing list

info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

[ronald kuivila]

Hi Scott,


  SynthDesc sounds like the right place to me.  This is entirely in  
the language so the file format could be made extensible without any  
impact on the server.  SynthDef-store could have an argument that  
specifies the information.

  Perhaps the SynthDesc should contain the name of the SynthDef so  
that you can do UI variants.  (Then
  a synthdef named \compander could have variants with different  
control ranges for  \limiter,
\compressor, \expander, etc and possibly different UI's).

While we are on the subject, does anyone out there use anything other  
than the global synthdef library?


RJK


On Jul 12, 2008, at 8:41 AM, Scott Wilson wrote:

> It seems to me that maybe the def should be associated with the  
> other data, rather than the other way around as we've been discussing.
>
> Perhaps there should be a scsynthdesc file format (or something  
> like it) which would contain all the data in a SynthDesc plus  
> specs, a default GUI (or enough info to generate one), etc. This  
> could contain the synthdef itself, and the server could be adjusted  
> to extract it if need be. (Or maybe this could be a bundle of some  
> sort which the server will read). This would keep the server  
> specific info separate while allowing the other stuff to be  
> conveniently packaged. Normal synthdefs files would still work and  
> remain lightweight, so this new format could be optional.
>
> You could associate specs, GUIs, whatever with variants if desired,  
> or have global ones.
>
> S.
>
>
> On 12 Jul 2008, at 13:16, ronald kuivila wrote:
>
>> Hi all,
>>
>>  It can be useful to reuse a synthdef with different range  
>> constraints on its controls. So controlspecs could naturally be  
>> part of an expansion of the role of variants.  The variant would  
>> have the controlspecs, but might evolve to have a bunch of other  
>> stuff (preferred GUI, connection specifications in the manner of  
>> cruxxial, etc).
>>
>>  The separate file approach reflects the reality that the specs  
>> being provided are irrelevant to the server.  This might be
>> better in the long term as it keeps the server insulated from any  
>> added complexity.  But it is certainly true that an integrated  
>> file simplified bookkeeping.
>>
>> RJK
>>
>>
>>
>> On Jul 9, 2008, at 12:44 PM, stefan kersten wrote:
>>
>>> On 09.07.2008, at 15:03, Dan Stowell wrote:
>>>> This is something that comes up from time to time - I agree it  
>>>> would
>>>> be helpful to have some kind of spec data written, for various
>>>> reasons. It would be very helpful for people using non-sclang
>>>> approaches to communicating with scsynth, for example.
>>>>
>>>> When you wrote "save control specs along with synthdefs", my first
>>>> thought was of a SEPARATE file containing the spec data (e.g. an  
>>>> ASCII
>>>> file called *.scspec). Would that be reasonable? It would have the
>>>> benefit of making no changes to scsynth or to the .scsyndef format.
>>>>
>>>> I was working on some scplug stuff and thinking: "I wish I could
>>>> access the synth specs from Javascript". With ascii spec data I  
>>>> could
>>>> do that :)
>>>>
>>>> If wanted, we could make it a switchable option - to save time/
>>>> space,
>>>> users could opt not to generate these spec files.
>>>
>>> intuitively i'd argue for adding the spec fields to the synthdef  
>>> directly.
>>> there'd be only one file to move around or delete and things  
>>> cannot get out of
>>> sync; imagine a synthdef written without a spec file while an  
>>> older file still
>>> exists.
>>>
>>> currently a synthdef file looks like this (from the documentation):
>>>
>>> int32 - four byte file type id containing the ASCII characters:  
>>> "SCgf"
>>> int32 - file version, currently zero.
>>> int16 - number of synth definitions in this file (D).
>>> [synth-definition] * D
>>>
>>> so it'd be straightforward to bump the version number and add a  
>>> metadata
>>> section before the synth definitions (not backwards compatible).  
>>> the reason
>>> for not adding it after the synthdefs is that they cannot be  
>>> skipped easily
>>> because the section size is unknown; each synthdef would have to  
>>> be parsed
>>> before. so the new format could look like this:
>>>
>>> int32 - four byte file type id containing the ASCII characters:  
>>> "SCgf"
>>> int32 - file version, currently zero.
>>> int32 - metadata section bytes (M)
>>> [ metadata byte ] * B
>>> int16 - number of synth definitions in this file (D).
>>> [synth-definition] * D
>>>
>>> as to the metadata format, i think that json (as suggested by  
>>> felix) is a good
>>> idea. in javascript e.g. you would just skip the first 8 bytes,  
>>> read the next
>>> n bytes and interpret the string.
>>>
>>> maybe we should also review another suggestion that has been made  
>>> in the past:
>>> string arguments to ugens. for static strings at least the  
>>> following could
>>> work:
>>>
>>> * each synthdef contains a symbol table that is read from the  
>>> file and stored
>>>  in the server object
>>> * string arguments to ugens are compiled as an index and the  
>>> corresponding
>>>  string is added to the symbol table
>>> * ugens can then query symbol table strings by index
>>>
>>> the format could be:
>>>
>>> int32 symbol table section bytes
>>> string1\0
>>> string2\0
>>> ...
>>>
>>> that's pretty much how csound does it i think, but it doesn't  
>>> allow setting
>>> argument strings dynamically.
>>>
>>> thoughts?
>>>
>>> <sk>
>>>
>>>
>>> _______________________________________________
>>> sc-dev mailing list
>>>
>>> info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de: 
>>> 8888/MusicTechnology/880
>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>>
>>
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de: 
>> 8888/MusicTechnology/880
>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/ 
> MusicTechnology/880
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>

_______________________________________________
sc-dev mailing list

info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

[Scott Wilson-3]

On 12 Jul 2008, at 16:24, ronald kuivila wrote:

> Hi Scott,
>
>
> SynthDesc sounds like the right place to me.  This is entirely in  
> the language so the file format could be made extensible without any  
> impact on the server.  SynthDef-store could have an argument that  
> specifies the information.
>
> Perhaps the SynthDesc should contain the name of the SynthDef so  
> that you can do UI variants.  (Then
> a synthdef named \compander could have variants with different  
> control ranges for  \limiter,
> \compressor, \expander, etc and possibly different UI's).
>
> While we are on the subject, does anyone out there use anything  
> other than the global synthdef library?

def or desc lib?

S.

_______________________________________________
sc-dev mailing list

info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

[ronald kuivila]

I meant the desc lib

RJK

On Jul 12, 2008, at 11:33 AM, Scott Wilson wrote:

>
> On 12 Jul 2008, at 16:24, ronald kuivila wrote:
>
>> Hi Scott,
>>
>>
>> SynthDesc sounds like the right place to me.  This is entirely in  
>> the language so the file format could be made extensible without  
>> any impact on the server.  SynthDef-store could have an argument  
>> that specifies the information.
>>
>> Perhaps the SynthDesc should contain the name of the SynthDef so  
>> that you can do UI variants.  (Then
>> a synthdef named \compander could have variants with different  
>> control ranges for  \limiter,
>> \compressor, \expander, etc and possibly different UI's).
>>
>> While we are on the subject, does anyone out there use anything  
>> other than the global synthdef library?
>
> def or desc lib?
>
> S.
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/ 
> MusicTechnology/880
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>

_______________________________________________
sc-dev mailing list

info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

[nescivi]

Hiho,

I believe I have for some things (in the SenseWorld quark), since it seemed an
interesting way to bundle a set of synthdefs for a specific purpose.

sincerely,
Marije

On Saturday 12 July 2008 12:16:17 ronald kuivila wrote:

> I meant the desc lib
>
> RJK
>
> On Jul 12, 2008, at 11:33 AM, Scott Wilson wrote:
> > On 12 Jul 2008, at 16:24, ronald kuivila wrote:
> >> Hi Scott,
> >>
> >>
> >> SynthDesc sounds like the right place to me.  This is entirely in
> >> the language so the file format could be made extensible without
> >> any impact on the server.  SynthDef-store could have an argument
> >> that specifies the information.
> >>
> >> Perhaps the SynthDesc should contain the name of the SynthDef so
> >> that you can do UI variants.  (Then
> >> a synthdef named \compander could have variants with different
> >> control ranges for  \limiter,
> >> \compressor, \expander, etc and possibly different UI's).
> >>
> >> While we are on the subject, does anyone out there use anything
> >> other than the global synthdef library?
> >
> > def or desc lib?
> >
> > S.

_______________________________________________
sc-dev mailing list

info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

[stefan kersten-2]

On 12.07.2008, at 17:24, ronald kuivila wrote:

>  SynthDesc sounds like the right place to me.  This is entirely in  
> the language so the file format could be made extensible without  
> any impact on the server.  SynthDef-store could have an argument  
> that specifies the information.
>
>  Perhaps the SynthDesc should contain the name of the SynthDef so  
> that you can do UI variants.  (Then
>  a synthdef named \compander could have variants with different  
> control ranges for  \limiter,
> \compressor, \expander, etc and possibly different UI's).

sounds good, however i wouldn't discard the idea of the annotation  
system being language agnostic (and thus using some common file  
format like e.g. json). it would be nice if an instrument or effect  
designed in sclang could be used e.g. in haskell with the same set of  
control ranges, default values, etc.

<sk>



_______________________________________________
sc-dev mailing list

info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/