Nabble - SuperCollider Developers New (Use this!!!!)

SF.net SVN: supercollider:[9820] trunk

2010-02-09T10:24:05Z

Revision: 9820
http://supercollider.svn.sourceforge.net/supercollider/?rev=9820&view=rev
Author: danstowell
Date: 2010-02-09 18:24:05 +0000 (Tue, 09 Feb 2010)

Log Message:
-----------
reorganise furniture: add new folders in root; rm unneeded xcode-related folder

Added Paths:
-----------
trunk/common/
trunk/iphone/
trunk/mac/

Removed Paths:
-------------
trunk/Intermediate Build Files/

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: SynthDef method cleanup

2010-02-09T09:54:21Z

I rely on things written to disk for NRT.

Josh

On Feb 9, 2010, at 8:36 AM, Scott Wilson wrote:

> I also see a use case for writing to disk. I had older code which mass produced synthdefs based on Loris data. Recreating these took a significant amount of time, so it was useful to have them on disk (in a separate folder so they were only loaded when needed) pre-done.
>
> I agree that sending is by far the norm though.
>
> S.
>
> On 9 Feb 2010, at 14:28, Dan Stowell wrote:
>
>> 2010/2/9 adc <[hidden email]>:
>>> Dan - i don't agree with your second statement. i've never ever seen users
>>> depend on writing defs to disk. i have countless times seen users confused
>>> (myself included) by old defs loaded from disk. not to mention the file
>>> privilege installation issues for admins installing sc etc.
>>>
>>> agree with fredrik here:
>>> I think relying on some old file lying somewhere that has a synthdef you
>>> wrote 6 months ago to still be there,
>>> and not having been accidentally overwrotten by a new synthdef with the same
>>> name is asking for trouble,
>>> and should be discouraged.
>>> the rule should be: if you rely on something to be there, please put it in
>>> your startup files.
>>> and for completeness, when you boot a server, send it all the synthdefs
>>> currently in the Lib,
>>> so it can "just work". that is even safer to keep things in sync than
>>> reading from disk.
>>
>> In my work I create classes which have associated synthdefs. I use
>> writeOnce to create them as needed. The amount of synthdefs actually
>> weighs down startup quite a lot if I change that to writeDefFile, it's
>> quite noticeable. I don't want my startup to be generating these
>> synthdefs every single time.
>>
>>> thanks for the discussion! it will be great when all this synthdef mystery
>>> is gone ;-)
>>
>> Yes :)
>>
>> Dan
>>
>>> best, adc
>>>
>> --
>> http://www.mcld.co.uk
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> 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 (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> 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 (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: show default server?

2010-02-09T09:13:46Z

On Tue, Feb 9, 2010 at 11:49 AM, Scott Wilson <[hidden email]> wrote:

If anybody does that, they're probably aware of the problem, and in trouble, as the server window default buttons already repopulate s.

In other words, it is a bug in the current default button behavior. :) A button on a standard interface window shouldn't get the user into trouble (unless you want to make it a documented rule that the user must never use 's' for anything other than a server, which seems draconian at best -- s == Server.default is a common practice, but the mere fact that it's common does not mean that doing something different is incorrect practice).

hjh

--
James Harkins /// dewdrop world
[hidden email]
http://www.dewdrop-world.net

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

Re: show default server?

2010-02-09T08:49:14Z

If anybody does that, they're probably aware of the problem, and in trouble, as the server window default buttons already repopulate s.

But I don't believe for a second that anyone does that.

On 9 Feb 2010, at 16:40, James Harkins wrote:

How about, check to see if 's' is a Server and change it if so - otherwise assume the user is using 's' for something else and don't step on their toes?
hjh

On Tue, Feb 9, 2010 at 8:04 AM, Scott Wilson <[hidden email]> wrote:

I think it's like this to support changing from the gui window. If it defaulted to true I think it wouldn't matter.

Do we even really need a flag? s == Server.default is so pervasive in practice that I'd be surprised if anyone would be bothered by this change. On the contrary not having it seems to cause problems.

--
James Harkins /// dewdrop world
[hidden email]
http://www.dewdrop-world.net

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

Re: show default server?

2010-02-09T08:40:01Z

How about, check to see if 's' is a Server and change it if so - otherwise assume the user is using 's' for something else and don't step on their toes?
hjh

On Tue, Feb 9, 2010 at 8:04 AM, Scott Wilson <[hidden email]> wrote:

I think it's like this to support changing from the gui window. If it defaulted to true I think it wouldn't matter.

Do we even really need a flag? s == Server.default is so pervasive in practice that I'd be surprised if anyone would be bothered by this change. On the contrary not having it seems to cause problems.

--
James Harkins /// dewdrop world
[hidden email]
http://www.dewdrop-world.net

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

Re: SynthDef method cleanup

2010-02-09T08:36:38Z

I also see a use case for writing to disk. I had older code which mass
produced synthdefs based on Loris data. Recreating these took a
significant amount of time, so it was useful to have them on disk (in
a separate folder so they were only loaded when needed) pre-done.

I agree that sending is by far the norm though.

S.

On 9 Feb 2010, at 14:28, Dan Stowell wrote:

> 2010/2/9 adc <[hidden email]>:
>> Dan - i don't agree with your second statement. i've never ever
>> seen users
>> depend on writing defs to disk. i have countless times seen users
>> confused
>> (myself included) by old defs loaded from disk. not to mention the
>> file
>> privilege installation issues for admins installing sc etc.
>>
>> agree with fredrik here:
>> I think relying on some old file lying somewhere that has a
>> synthdef you
>> wrote 6 months ago to still be there,
>> and not having been accidentally overwrotten by a new synthdef with
>> the same
>> name is asking for trouble,
>> and should be discouraged.
>> the rule should be: if you rely on something to be there, please
>> put it in
>> your startup files.
>> and for completeness, when you boot a server, send it all the
>> synthdefs
>> currently in the Lib,
>> so it can "just work". that is even safer to keep things in sync than
>> reading from disk.
>
> In my work I create classes which have associated synthdefs. I use
> writeOnce to create them as needed. The amount of synthdefs actually
> weighs down startup quite a lot if I change that to writeDefFile, it's
> quite noticeable. I don't want my startup to be generating these
> synthdefs every single time.
>
>> thanks for the discussion! it will be great when all this synthdef
>> mystery
>> is gone ;-)
>
> Yes :)
>
> Dan
>
>> best, adc
>>
> --
> http://www.mcld.co.uk
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> 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 (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: The Plot. (was plotting behaviour) : Quark or Common?

2010-02-09T08:21:02Z

Hi Julian,

None, it just didn't work the last time I tried;)

Looking at the code, there will be some issues if you want to draw the
graphs in different colors.
The drawData method needs to flop the array and then draw each one
separately so it can have a different color.

Not a big deal, but the current approach can work for elements of
different sizes, which is very nice.

RJK

On Feb 9, 2010, at 10:26 AM, Julian Rohrhuber wrote:

> Hi Ron,
>
> With the method I suggested it looks like this - what's the
> difference?
>
>
> [
> (1..100)/100, ((1..100)/100).squared
> ].flop.bubble.plot2
>
>
>
>
>
> On 09.02.2010, at 15:25, ronald kuivila wrote:
>
>> Hi Julian,
>>
>> I don't see how it does.
>> How can I plot
>>
>> (0,0.01..1) on top of (0,0.01..1).squared
>>
>> so that they are overlapping in the same Rect?
>>
>> With the extension I posted, it would look like:
>> [
>> (1..100)/100, ((1..100)/100).squared
>> ].plot2(overlap:true)
>>
>>
>> <Picture 1.png>
>>
>>
>>
>> RJK
>>
>> PS: This definitely should go in common.
>>
>>
>> On Feb 9, 2010, at 4:41 AM, Julian Rohrhuber wrote:
>>
>>> x = [(0..100), (200..300), (400..500)];
>>> x.flop.bubble.plot2;
>>
>> On Feb 9, 2010, at 7:19 AM, Julian Rohrhuber wrote:
>>
>>> Hi Ron,
>>>
>>> just to be sure, I've attached a new version that has a few fixes
>>> (renamed MultiPlot to Plotter). I think it does what you intend,
>>> but let's see.
>>>
>>>
>>>
>>>
>>> On 09.02.2010, at 13:09, ronald kuivila wrote:
>>>
>>>> var <>overlap;
>>>>
>>>> updatePlotBounds {
>>>> var deltaY = if(this.numChannels > 1 ) { gapY } { 0.0 };
>>>> var distY = bounds.height / this.numChannels;
>>>> var height = max(20, distY - deltaY);
>>>> var min, max;
>>>>
>>>> if (overlap) {
>>>> plotViews.do { |view, i|
>>>> view.bounds_(bounds)
>>>> };
>>>> plotViews[1..].do{ | pv | pv.backgroundColor.alpha_(0) };
>>>>
>>>> min = plotViews.collect { | v | v.spec.minval }.minItem;
>>>> max = plotViews.collect { | v | v.spec.maxval }.maxItem;
>>>> plotViews.do { | v | v.spec.minval_(min); v.spec.maxval_(max) };
>>>> }{
>>>> plotViews.do { |view, i|
>>>> view.bounds_(
>>>> Rect(bounds.left, distY * i + bounds.top, bounds.width,
>>>> height)
>>>> )
>>>> };
>>>> }
>>>> }
>>>> }
>>> <PlotView.sc><PlotWindow.scd>
>>
> <Screen shot 2010-02-09 at 16.23.56.png>

Re: SynthDef method cleanup

2010-02-09T07:58:46Z

On Tue, Feb 9, 2010 at 10:44 AM, ronald kuivila <[hidden email]> wrote:

Hi all,

What if the storage policy were associated with the SynthDescLib rather than the SynthDef?

So SynthDescLib.global would not store to disk and SynthDescLib.system would.

*giggles* After explaining why I hate it when system defs are written to disk... grrrrr...

hjh

--
James Harkins /// dewdrop world
[hidden email]
http://www.dewdrop-world.net

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

Re: SynthDef method cleanup

2010-02-09T07:44:03Z

Hi all,

What if the storage policy were associated with the SynthDescLib rather than the SynthDef?

So SynthDescLib.global would not store to disk and SynthDescLib.system would.

SynthDef:add could take the name of a SynthDescLib as an argument.

(This might make a bit of trouble for Patterns as you might then need to set ~synthLib. James, Julian?)

RJK

On Feb 9, 2010, at 9:58 AM, James Harkins wrote:

On Feb 9, 2010, at 8:35 AM, Fredrik Olofsson wrote:

Dan - i don't agree with your second statement. i've never ever seen users depend on writing defs to disk.

pvcalc makes huge synthdefs that can't be sent by udp. Maybe the solution is to resort transparently to a temp file that is deleted after the server receives the def, something like the following pseudocode:

fork {
def.store;
s.sync;
"rm -f %".format(path to def).unixCmd
}

hjh

: H. James Harkins
: [hidden email]
: http://www.dewdrop-world.net
.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

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

Re: The Plot. (was plotting behaviour) : Quark or Common?

2010-02-09T07:26:05Z

Hi Ron,

With the method I suggested it looks like this - what's the difference?

[
(1..100)/100, ((1..100)/100).squared
].flop.bubble.plot2

On 09.02.2010, at 15:25, ronald kuivila wrote:

> Hi Julian,
>
> I don't see how it does.
> How can I plot
>
> (0,0.01..1) on top of (0,0.01..1).squared
>
> so that they are overlapping in the same Rect?
>
> With the extension I posted, it would look like:
> [
> (1..100)/100, ((1..100)/100).squared
> ].plot2(overlap:true)
>
>
> <Picture 1.png>
>
>
>
> RJK
>
> PS: This definitely should go in common.
>
>
> On Feb 9, 2010, at 4:41 AM, Julian Rohrhuber wrote:
>
>> x = [(0..100), (200..300), (400..500)];
>> x.flop.bubble.plot2;
>
> On Feb 9, 2010, at 7:19 AM, Julian Rohrhuber wrote:
>
>> Hi Ron,
>>
>> just to be sure, I've attached a new version that has a few fixes (renamed MultiPlot to Plotter). I think it does what you intend, but let's see.
>>
>>
>>
>>
>> On 09.02.2010, at 13:09, ronald kuivila wrote:
>>
>>> var <>overlap;
>>>
>>> updatePlotBounds {
>>> var deltaY = if(this.numChannels > 1 ) { gapY } { 0.0 };
>>> var distY = bounds.height / this.numChannels;
>>> var height = max(20, distY - deltaY);
>>> var min, max;
>>>
>>> if (overlap) {
>>> plotViews.do { |view, i|
>>> view.bounds_(bounds)
>>> };
>>> plotViews[1..].do{ | pv | pv.backgroundColor.alpha_(0) };
>>>
>>> min = plotViews.collect { | v | v.spec.minval }.minItem;
>>> max = plotViews.collect { | v | v.spec.maxval }.maxItem;
>>> plotViews.do { | v | v.spec.minval_(min); v.spec.maxval_(max) };
>>> }{
>>> plotViews.do { |view, i|
>>> view.bounds_(
>>> Rect(bounds.left, distY * i + bounds.top, bounds.width, height)
>>> )
>>> };
>>> }
>>> }
>>> }
>> <PlotView.sc><PlotWindow.scd>
>

Screen shot 2010-02-09 at 16.23.56.png (33K) Download Attachment

Re: show default server?

2010-02-09T07:16:24Z

makes sense. Just leave the flag away, I'd say.

On 09.02.2010, at 14:04, Scott Wilson wrote:

> I think it's like this to support changing from the gui window. If it defaulted to true I think it wouldn't matter.
>
> Do we even really need a flag? s == Server.default is so pervasive in practice that I'd be surprised if anyone would be bothered by this change. On the contrary not having it seems to cause problems.
>
> S.
>
> On 9 Feb 2010, at 12:51, Julian Rohrhuber wrote:
>
>> setters shouldn't have two args really. So I think it could be a flag in the class.
>>
>>
>> On 09.02.2010, at 13:40, Scott Wilson wrote:
>>
>>> Is there any reason why sync_s should not default to true?
>>>
>>> I find this sort of construction:
>>>
>>> Server.default = s = Server.internal;
>>>
>>> very clunky and prone to order mistakes for beginners.
>>>
>>> S.
>>>
>>> On 16 May 2009, at 17:20, Alberto de Campo wrote:
>>>
>>>> hi all,
>>>>
>>>> I find the question 'which server is currently default' occurs really often,
>>>> and is a regular source of confusion for students. It occurred to me that the
>>>> server windows should just show that.
>>>>
>>>> below the diff for an attempt - ok like that?
>>>> any better ideas? opinions?
>>>>
>>>>
>>>> best, adc
>>>>
>>>>
>>>> Index: Control/Server.sc
>>>> ===================================================================
>>>> --- Control/Server.sc (revision 9164)
>>>> +++ Control/Server.sc (working copy)
>>>> @@ -185,7 +185,7 @@
>>>> }
>>>>
>>>> Server : Model {
>>>> - classvar <>local, <>internal, <>default, <>named, <>set, <>program;
>>>> + classvar <>local, <>internal, <default, <>named, <>set, <>program;
>>>>
>>>> var <name, <>addr, <clientID=0;
>>>> var <isLocal, <inProcess, <>sendQuit, <>remoteControlled;
>>>> @@ -212,6 +212,12 @@
>>>>
>>>> var <pid;
>>>>
>>>> + *default_ { |server, sync_s = false|
>>>> + default = server; // sync with s?
>>>> + if (sync_s, { thisProcess.interpreter.s = server });
>>>> + this.all.do(_.changed(\default));
>>>> + }
>>>> +
>>>>
>>>> Index: GUI/PlusGUI/Control/ServerPlusGUI.sc
>>>> ===================================================================
>>>> --- GUI/PlusGUI/Control/ServerPlusGUI.sc (revision 9164)
>>>> +++ GUI/PlusGUI/Control/ServerPlusGUI.sc (working copy)
>>>> @@ -15,7 +15,7 @@
>>>> }
>>>>
>>>> makeGui { arg w;
>>>> - var active, booter, killer, makeDefault, running, booting, stopped, bundling;
>>>> + var active, booter, killer, makeDefault, running, booting, stopped, bundling, showDefault;
>>>> var recorder, scoper;
>>>> var countsViews, ctlr;
>>>> var dumping = false, label, gui, font, volumeNum;
>>>> @@ -68,12 +68,10 @@
>>>> makeDefault = gui.button.new(w, Rect(0,0, 54, 18));
>>>> makeDefault.font = font;
>>>> makeDefault.canFocus = false;
>>>> - makeDefault.states = [["-> default", Color.black, Color.clear]];
>>>> - makeDefault.action = {
>>>> - thisProcess.interpreter.s = this;
>>>> - Server.default = this;
>>>> - };
>>>> -
>>>> + makeDefault.states = [["-> default", Color.black, Color.clear], ["-> default", Color.black, Color.green.alpha_(0.2)]];
>>>> + makeDefault.value_((this == Server.default).binaryValue);
>>>> + makeDefault.action = { Server.default_(this, true) };
>>>> +
>>>> //w.view.decorator.nextLine;
>>>>
>>>> recorder = gui.button.new(w, Rect(0,0, 66, 18));
>>>> @@ -169,6 +167,7 @@
>>>> window = nil;
>>>> ctlr.remove;
>>>> };
>>>> +
>>>> },{
>>>> running = {
>>>> active.stringColor_(Color.new255(74, 120, 74));
>>>> @@ -202,6 +201,12 @@
>>>> ctlr.remove;
>>>> };
>>>> });
>>>> +
>>>> + showDefault = {
>>>> + "// Server.default: % - s: % // \n\n".postf(Server.default, thisProcess.interpreter.s);
>>>> + makeDefault.value = (Server.default == this).binaryValue;
>>>> + };
>>>> +
>>>> if(serverRunning,running,stopped);
>>>>
>>>> w.view.decorator.nextLine;
>>>> @@ -288,8 +293,10 @@
>>>> if (unicode == 16rF700, { slider.increment; });
>>>> if (unicode == 16rF703, { slider.increment; });
>>>> if (unicode == 16rF701, { slider.decrement; });
>>>> - if (unicode == 16rF702, { slider.decrement; }); nil;
>>>> - });
>>>> + if (unicode == 16rF702, { slider.decrement; });
>>>> + nil;
>>>> + })
>>>> + ;
>>>> volController = SimpleController(volume)
>>>> .put(\amp, {|changer, what, vol|
>>>> {
>>>> @@ -325,7 +332,9 @@
>>>> .put(\cmdPeriod,{
>>>> recorder.setProperty(\value,0);
>>>> })
>>>> - .put(\bundling, bundling);
>>>> + .put(\bundling, bundling)
>>>> + .put(\default, showDefault);
>>>> +
>>>> this.startAliveThread;
>>>> }
>>>> }
>>>>
>>>> --
>>>> --
>>>> Alberto de Campo
>>>> Bergstrasse 59/33
>>>> A-8020 Graz, Austria
>>>> e-mail : [hidden email]
>>>> --
>>>>
>>>> _______________________________________________
>>>> sc-dev mailing list
>>>>
>>>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>>> 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 (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>> 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 (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> 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 (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: SynthDef method cleanup

2010-02-09T06:58:52Z

On Feb 9, 2010, at 8:35 AM, Fredrik Olofsson wrote:

Dan - i don't agree with your second statement. i've never ever seen users depend on writing defs to disk.

pvcalc makes huge synthdefs that can't be sent by udp. Maybe the solution is to resort transparently to a temp file that is deleted after the server receives the def, something like the following pseudocode:

fork {

def.store;

s.sync;

"rm -f %".format(path to def).unixCmd

}

hjh

: H. James Harkins

: [hidden email]

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

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

"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal." -- Whitman

Where to put system defs? (spun off from SynthDef cleanup)

2010-02-09T06:56:24Z

On Feb 9, 2010, at 9:28 AM, Dan Stowell wrote:

In my work I create classes which have associated synthdefs. I use
writeOnce to create them as needed. The amount of synthdefs actually
weighs down startup quite a lot if I change that to writeDefFile, it's
quite noticeable. I don't want my startup to be generating these
synthdefs every single time.

As this is a tangent to the main SynthDef discussion, I thought it best to start a new thread.

I have a real pet peeve about classes that add weight to the synthdefs directory. At the same time, I also have classes that require SynthDefs to be there when needed -- so I put my money where my mouth is and instead, now I use dependencies to send SynthDefs when a server boots.

http://quarks.svn.sourceforge.net/viewvc/quarks/dewdrop_lib/ddwChucklib/Prototypes/startup00-ddwSynths.scd

This might not be an ideal solution for everyone, sure, but there's an interesting problem lurking in there. As you scale up the number of installed extensions, if a certain percentage of them add their own set of SynthDefs, where do you put them?

In principle, I think it would be ideal to send SynthDefs only when they're going to be used and not before. In practice, that proved to be a PITA in my work. I'm not sure which is the lesser of evils. My way takes a bit more care in the initial coding, but it does have the advantage that a user who installs dewdrop_lib, and then uninstalls it later, doesn't have any persistent cruft in the filesystem (whereas writeOnce leaves litter behind). To me, it's worth the extra effort to be more polite to the user.

hjh

: H. James Harkins

: [hidden email]

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

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

"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal." -- Whitman

Re: SynthDef method cleanup

2010-02-09T06:55:07Z

9 feb 2010 kl. 15.28 skrev Dan Stowell:

2010/2/9 adc <[hidden email]>:
Dan - i don't agree with your second statement. i've never ever seen users
depend on writing defs to disk. i have countless times seen users confused
(myself included) by old defs loaded from disk. not to mention the file
privilege installation issues for admins installing sc etc.

agree with fredrik here:
I think relying on some old file lying somewhere that has a synthdef you
wrote 6 months ago to still be there,
and not having been accidentally overwrotten by a new synthdef with the same
name is asking for trouble,
and should be discouraged.
the rule should be: if you rely on something to be there, please put it in
your startup files.
and for completeness, when you boot a server, send it all the synthdefs
currently in the Lib,
so it can "just work". that is even safer to keep things in sync than
reading from disk.

In my work I create classes which have associated synthdefs. I use
writeOnce to create them as needed. The amount of synthdefs actually
weighs down startup quite a lot if I change that to writeDefFile, it's
quite noticeable. I don't want my startup to be generating these
synthdefs every single time.

there should be a better way to do this than writeOnce. i have old classes that uses writeOnce as well, but stopped using it because of a fundamental flaw: when you distribute these classes and have updated the synthdef, you need to tell the users to manually delete the def file and recompile. how confusing and error prone isn't that? same issue with storeOnce.

fredrikolofsson.com klippav.org musicalfieldsforever.com

Re: SynthDef method cleanup

2010-02-09T06:52:05Z

On Tuesday 09 February 2010 09:20:36 James Harkins wrote:

> On Feb 9, 2010, at 9:09 AM, ronald kuivila wrote:
> > Hi all,
> >
> > My guess is that storing synthdef files comes from imagining the
> > server as a shared server (like a latter day Samson box or something).
> > Come to think of it, there is a lot of structure there that is
> > probably rarely, if ever, used. For example, does anyone use a
> > SynthDescLib other
> > than SynthDescLib.global ?
>
> Marije and I do.

And I even think it should be encouraged more, as it provides interesting ways
of organising synths, by project or function, and browsing them in different
groups in the SynthDefBrowser.
And it provides a way of saving the synthdefs in custom paths on your disk,
from which you can read them later on. I've found this specifically useful as
I've built a system where I concatenate synths from signals and various
spatialisation methods, so I do not have one definition in one place.

It needs to be documented much better, which is still on my TODO list :)

sincerely,
Marije

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: SynthDef method cleanup

2010-02-09T06:28:45Z

2010/2/9 adc <[hidden email]>:

> Dan - i don't agree with your second statement. i've never ever seen users
> depend on writing defs to disk. i have countless times seen users confused
> (myself included) by old defs loaded from disk. not to mention the file
> privilege installation issues for admins installing sc etc.
>
> agree with fredrik here:
> I think relying on some old file lying somewhere that has a synthdef you
> wrote 6 months ago to still be there,
> and not having been accidentally overwrotten by a new synthdef with the same
> name is asking for trouble,
> and should be discouraged.
> the rule should be: if you rely on something to be there, please put it in
> your startup files.
> and for completeness, when you boot a server, send it all the synthdefs
> currently in the Lib,
> so it can "just work". that is even safer to keep things in sync than
> reading from disk.

In my work I create classes which have associated synthdefs. I use
writeOnce to create them as needed. The amount of synthdefs actually
weighs down startup quite a lot if I change that to writeDefFile, it's
quite noticeable. I don't want my startup to be generating these
synthdefs every single time.

> thanks for the discussion! it will be great when all this synthdef mystery
> is gone ;-)

Yes :)

Dan

> best, adc
>
--
http://www.mcld.co.uk

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: The Plot. (was plotting behaviour) : Quark or Common?

2010-02-09T06:25:27Z

Hi Julian,

I don't see how it does.

How can I plot

(0,0.01..1) on top of (0,0.01..1).squared

so that they are overlapping in the same Rect?

With the extension I posted, it would look like:

[

(1..100)/100, ((1..100)/100).squared

].plot2(overlap:true)

RJK

PS: This definitely should go in common.

On Feb 9, 2010, at 4:41 AM, Julian Rohrhuber wrote:

x = [(0..100), (200..300), (400..500)];
x.flop.bubble.plot2;

On Feb 9, 2010, at 7:19 AM, Julian Rohrhuber wrote:

Hi Ron,

just to be sure, I've attached a new version that has a few fixes (renamed MultiPlot to Plotter). I think it does what you intend, but let's see.

On 09.02.2010, at 13:09, ronald kuivila wrote:

var <>overlap;

updatePlotBounds {
var deltaY = if(this.numChannels > 1 ) { gapY } { 0.0 };
var distY = bounds.height / this.numChannels;
var height = max(20, distY - deltaY);
var min, max;

if (overlap) {
plotViews.do { |view, i|
view.bounds_(bounds)
};
plotViews[1..].do{ | pv | pv.backgroundColor.alpha_(0) };

min = plotViews.collect { | v | v.spec.minval }.minItem;
max = plotViews.collect { | v | v.spec.maxval }.maxItem;
plotViews.do { | v | v.spec.minval_(min); v.spec.maxval_(max) };
}{
plotViews.do { |view, i|
view.bounds_(
Rect(bounds.left, distY * i + bounds.top, bounds.width, height)
)
};
}
}
}
<PlotView.sc><PlotWindow.scd>

Re: SynthDef method cleanup

2010-02-09T06:21:29Z

Ron - see marije's message in this thread - she does

2010/2/9 ronald kuivila <[hidden email]>:

> Hi all,
>
> My guess is that storing synthdef files comes from imagining the server as
> a shared server (like a latter day Samson box or something).
> Come to think of it, there is a lot of structure there that is probably
> rarely, if ever, used. For example, does anyone use a SynthDescLib other
> than SynthDescLib.global ?
>
> RJK
>
> On Feb 9, 2010, at 8:35 AM, Fredrik Olofsson wrote:
>
>> hi
>> my €1. there's so much confusion around all this. please let's make even
>> more drastic changes.
>>
>> make .send a very special case. sort of expert-mode. helpfile explains
>> it's a method only useful for optimising certain code.
>> make .load another very special case. also expert-mode. helpfile
>> explains about osc package size limit.
>> deprecate .play. it should go away. it only does harm. there's {}.play.
>> hide/privatise or even better remove all storing to disk. writeDef,
>> writeDefFile, writeOnce, store, storeOnce. come on - who really needs them?
>>
>>
>> Dan - i don't agree with your second statement. i've never ever seen
>> users depend on writing defs to disk. i have countless times seen users
>> confused (myself included) by old defs loaded from disk. not to mention the
>> file privilege installation issues for admins installing sc etc.
>>
>> _f
>>
>>
>>
>> 9 feb 2010 kl. 14.17 skrev Dan Stowell:
>>
>>> Yes I think .add is good. We *do* need to be harsh about deprecating,
>>> otherwise there's a risk we add one more method and all the others
>>> carry on in use, so we would have added to the complexity rather than
>>> reduced it!
>>>
>>>
>>>>> when is it _really_ necessary to store to disk?
>>>
>>> When you write a SynthDef one day and expect it to be there in future,
>>> without having to re-run the code every time you launch sc.
>>>
>>> Dan
>>>
>>>
>>>
>>> 2010/2/9 Scott Wilson <[hidden email]>:
>>>>
>>>> Actually given the arguments on semantics, I think I agree with this
>>>> approach.
>>>>
>>>> I'd say add 'add', change all general examples to use it, and deprecate
>>>> memStore.
>>>>
>>>> Perhaps we should publish some guidelines for method names.
>>>>
>>>> S.
>>>>
>>>> On 9 Feb 2010, at 10:55, adc wrote:
>>>>
>>>>> hi,
>>>>>
>>>>> one opinion:
>>>>>
>>>>> I think by default SynthDefs should just work as Synths and in
>>>>> patterns;
>>>>> so they should by default go to the server and the SynthDescLib.
>>>>> the clearest name I'v heard so far is:
>>>>>
>>>>> SynthDef(\bla, { ... }).add; // = current memStore
>>>>>
>>>>> If one does not want synthdefs in the lib (e.g. for efficiency
>>>>> optimisation),
>>>>> one could do :
>>>>>
>>>>> SynthDef(\bla, { ... }).send; // send to all running servers by
>>>>> default,
>>>>> unless server is given.
>>>>>
>>>>> To remove a synthdef, the clearest so far:
>>>>>
>>>>> SynthDef.remove(\bla); // clear it from SynthDescLib and from all
>>>>> running
>>>>> servers
>>>>> ( for symmetry, one could also provide : SynthDef.add(\bla, { ... });
>>>>> )
>>>>>
>>>>> Users should not have to worry about keeping in sync what the server
>>>>> knows
>>>>> and
>>>>> what synthdesclib knows. this would reduce beginners confusion a lot
>>>>> IMO.
>>>>>
>>>>>
>>>>> when is it _really_ necessary to store to disk?
>>>>>
>>>>> I sometimes find it puzzling that synthdefs that still lie around on
>>>>> disk
>>>>> get loaded on the server, so the server knows them, and they seem to
>>>>> work,
>>>>> but then, not having made them from code in the lang, patterns dont
>>>>> work.
>>>>>
>>>>> not storing to disk by default (unless explicitly forced) would remove
>>>>> that puzzle:
>>>>> when they are not there, they are not there.
>>>>>
>>>>> that would require touching up a lot of Synthdef code, but that code
>>>>> would
>>>>> get really simpler.
>>>>>
>>>>> just 2c,
>>>>> best, adc
>>>>>
>>>>>
>>>>> On Feb 9, 2010, at 11:26 AM, Julian Rohrhuber wrote:
>>>>>
>>>>>> Thank you for your comments. Much worse than flags are method and
>>>>>> argument names that center on implementation instead of behavior.
>>>>>> "memStore"
>>>>>> is a border case in a sense. What I find is that we desperately need
>>>>>> is a
>>>>>> more abstract method whose name does not reflect how a SynthDef is
>>>>>> made
>>>>>> accessible as to make it work, but clearly says that it does so. As it
>>>>>> is
>>>>>> the most common thing, it should be clear and short. While memStore
>>>>>> sticks
>>>>>> once one has learned it, it is not a nice thing to have in the code -
>>>>>> its
>>>>>> name has nothing to do with why we use it really.
>>>>>>
>>>>>> One possibility would be to make store like "memStore" by default, and
>>>>>> add diskStore. Flags in the class variables may be useful, but of
>>>>>> course are
>>>>>> ugly if you need a functionality only once. But well, let's hear some
>>>>>> more
>>>>>> opinions.. :)
>>>>>>
>>>>>>
>>>>>> On 09.02.2010, at 07:51, Pelle Nilsson wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Being only a new user still learning SC lurking on dev, I still can't
>>>>>>> resist commenting on this issue from a new user point of view:
>>>>>>>
>>>>>>> Julian Rohrhuber <[hidden email]> writes:
>>>>>>>
>>>>>>>> Some methods of SynthDef are a bit hard to read. I've tried to clear
>>>>>>>> thing up a bit and added a flag to send which stores the synthDesc
>>>>>>>> (see patch).
>>>>>>>>
>>>>>>>> I'm not sure what the general opinion about this is. My experience
>>>>>>>> is
>>>>>>>> that the combinatorics of methods are hard to explain and that
>>>>>>>> memStore is a too complicated name for a simple behaviour. To
>>>>>>>> understand the name, one has to understand the history of
>>>>>>>> supercollider. I would not be against using the method "add"
>>>>>>>> instead,
>>>>>>>> but as we are in a mess already, I tend to just make things work.
>>>>>>>
>>>>>>> It would be great to not use boolean flags here (or elsewhere). As a
>>>>>>> new
>>>>>>> user, or probably an old user reading old code later, it is
>>>>>>> impossible
>>>>>>> to read (or write) store(true), store(false), and store() and
>>>>>>> remember
>>>>>>> what they mean (and which one the last is equivalent to). I always
>>>>>>> use
>>>>>>> memStore and part of the reason is that I can remember what it does
>>>>>>> for
>>>>>>> sure. I would love if the other version was called diskStore or
>>>>>>> something similar.
>>>>>>>
>>>>>>> Knowing from other programming languages, trying to hide
>>>>>>> combinatorics
>>>>>>> of methods by putting several methods in the same one and using flags
>>>>>>> to
>>>>>>> select which of the hidden methods you really want to call was never
>>>>>>> a
>>>>>>> solution to the problem.
>>>>>>>
>>>>>>> As others already said, the store methods are confusing enough to new
>>>>>>> users already. It is great to hear that something is done about it,
>>>>>>> but
>>>>>>> I hope you dev guys end up agreeing on some other solution. :)
>>>>>>>
>>>>>>> IMHO and all that.
>>>>>>>
>>>>>>> --
>>>>>>> /Pelle
>>
>>
>> #|
>> fredrikolofsson.com klippav.org musicalfieldsforever.com
>> |#
>>
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscription, etc.):
>> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> 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 (subscription, etc.):
> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>

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

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: SynthDef method cleanup

2010-02-09T06:20:36Z

On Feb 9, 2010, at 9:09 AM, ronald kuivila wrote:

Hi all,

My guess is that storing synthdef files comes from imagining the server as a shared server (like a latter day Samson box or something).
Come to think of it, there is a lot of structure there that is probably rarely, if ever, used. For example, does anyone use a SynthDescLib other
than SynthDescLib.global ?

Marije and I do.

hjh

: H. James Harkins

: [hidden email]

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

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

"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal." -- Whitman

Re: SynthDef method cleanup

2010-02-09T06:09:44Z

Hi all,

My guess is that storing synthdef files comes from imagining the
server as a shared server (like a latter day Samson box or something).
Come to think of it, there is a lot of structure there that is
probably rarely, if ever, used. For example, does anyone use a
SynthDescLib other
than SynthDescLib.global ?

RJK

On Feb 9, 2010, at 8:35 AM, Fredrik Olofsson wrote:

> hi
> my €1. there's so much confusion around all this. please let's
> make even more drastic changes.
>
> make .send a very special case. sort of expert-mode. helpfile
> explains it's a method only useful for optimising certain code.
> make .load another very special case. also expert-mode. helpfile
> explains about osc package size limit.
> deprecate .play. it should go away. it only does harm. there's
> {}.play.
> hide/privatise or even better remove all storing to disk. writeDef,
> writeDefFile, writeOnce, store, storeOnce. come on - who really
> needs them?
>
>
> Dan - i don't agree with your second statement. i've never ever
> seen users depend on writing defs to disk. i have countless times
> seen users confused (myself included) by old defs loaded from disk.
> not to mention the file privilege installation issues for admins
> installing sc etc.
>
> _f
>
>
>
> 9 feb 2010 kl. 14.17 skrev Dan Stowell:
>
>> Yes I think .add is good. We *do* need to be harsh about deprecating,
>> otherwise there's a risk we add one more method and all the others
>> carry on in use, so we would have added to the complexity rather than
>> reduced it!
>>
>>
>>>> when is it _really_ necessary to store to disk?
>>
>> When you write a SynthDef one day and expect it to be there in
>> future,
>> without having to re-run the code every time you launch sc.
>>
>> Dan
>>
>>
>>
>> 2010/2/9 Scott Wilson <[hidden email]>:
>>> Actually given the arguments on semantics, I think I agree with this
>>> approach.
>>>
>>> I'd say add 'add', change all general examples to use it, and
>>> deprecate
>>> memStore.
>>>
>>> Perhaps we should publish some guidelines for method names.
>>>
>>> S.
>>>
>>> On 9 Feb 2010, at 10:55, adc wrote:
>>>
>>>> hi,
>>>>
>>>> one opinion:
>>>>
>>>> I think by default SynthDefs should just work as Synths and in
>>>> patterns;
>>>> so they should by default go to the server and the SynthDescLib.
>>>> the clearest name I'v heard so far is:
>>>>
>>>> SynthDef(\bla, { ... }).add; // = current memStore
>>>>
>>>> If one does not want synthdefs in the lib (e.g. for efficiency
>>>> optimisation),
>>>> one could do :
>>>>
>>>> SynthDef(\bla, { ... }).send; // send to all running servers by
>>>> default,
>>>> unless server is given.
>>>>
>>>> To remove a synthdef, the clearest so far:
>>>>
>>>> SynthDef.remove(\bla); // clear it from SynthDescLib and from all
>>>> running
>>>> servers
>>>> ( for symmetry, one could also provide : SynthDef.add(\bla,
>>>> { ... });
>>>> )
>>>>
>>>> Users should not have to worry about keeping in sync what the
>>>> server knows
>>>> and
>>>> what synthdesclib knows. this would reduce beginners confusion a
>>>> lot IMO.
>>>>
>>>>
>>>> when is it _really_ necessary to store to disk?
>>>>
>>>> I sometimes find it puzzling that synthdefs that still lie around
>>>> on disk
>>>> get loaded on the server, so the server knows them, and they seem
>>>> to work,
>>>> but then, not having made them from code in the lang, patterns
>>>> dont work.
>>>>
>>>> not storing to disk by default (unless explicitly forced) would
>>>> remove
>>>> that puzzle:
>>>> when they are not there, they are not there.
>>>>
>>>> that would require touching up a lot of Synthdef code, but that
>>>> code would
>>>> get really simpler.
>>>>
>>>> just 2c,
>>>> best, adc
>>>>
>>>>
>>>> On Feb 9, 2010, at 11:26 AM, Julian Rohrhuber wrote:
>>>>
>>>>> Thank you for your comments. Much worse than flags are method and
>>>>> argument names that center on implementation instead of
>>>>> behavior. "memStore"
>>>>> is a border case in a sense. What I find is that we desperately
>>>>> need is a
>>>>> more abstract method whose name does not reflect how a SynthDef
>>>>> is made
>>>>> accessible as to make it work, but clearly says that it does so.
>>>>> As it is
>>>>> the most common thing, it should be clear and short. While
>>>>> memStore sticks
>>>>> once one has learned it, it is not a nice thing to have in the
>>>>> code - its
>>>>> name has nothing to do with why we use it really.
>>>>>
>>>>> One possibility would be to make store like "memStore" by
>>>>> default, and
>>>>> add diskStore. Flags in the class variables may be useful, but
>>>>> of course are
>>>>> ugly if you need a functionality only once. But well, let's hear
>>>>> some more
>>>>> opinions.. :)
>>>>>
>>>>>
>>>>> On 09.02.2010, at 07:51, Pelle Nilsson wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Being only a new user still learning SC lurking on dev, I still
>>>>>> can't
>>>>>> resist commenting on this issue from a new user point of view:
>>>>>>
>>>>>> Julian Rohrhuber <[hidden email]> writes:
>>>>>>
>>>>>>> Some methods of SynthDef are a bit hard to read. I've tried to
>>>>>>> clear
>>>>>>> thing up a bit and added a flag to send which stores the
>>>>>>> synthDesc
>>>>>>> (see patch).
>>>>>>>
>>>>>>> I'm not sure what the general opinion about this is. My
>>>>>>> experience is
>>>>>>> that the combinatorics of methods are hard to explain and that
>>>>>>> memStore is a too complicated name for a simple behaviour. To
>>>>>>> understand the name, one has to understand the history of
>>>>>>> supercollider. I would not be against using the method "add"
>>>>>>> instead,
>>>>>>> but as we are in a mess already, I tend to just make things
>>>>>>> work.
>>>>>>
>>>>>> It would be great to not use boolean flags here (or elsewhere).
>>>>>> As a new
>>>>>> user, or probably an old user reading old code later, it is
>>>>>> impossible
>>>>>> to read (or write) store(true), store(false), and store() and
>>>>>> remember
>>>>>> what they mean (and which one the last is equivalent to). I
>>>>>> always use
>>>>>> memStore and part of the reason is that I can remember what it
>>>>>> does for
>>>>>> sure. I would love if the other version was called diskStore or
>>>>>> something similar.
>>>>>>
>>>>>> Knowing from other programming languages, trying to hide
>>>>>> combinatorics
>>>>>> of methods by putting several methods in the same one and using
>>>>>> flags to
>>>>>> select which of the hidden methods you really want to call was
>>>>>> never a
>>>>>> solution to the problem.
>>>>>>
>>>>>> As others already said, the store methods are confusing enough
>>>>>> to new
>>>>>> users already. It is great to hear that something is done about
>>>>>> it, but
>>>>>> I hope you dev guys end up agreeing on some other solution. :)
>>>>>>
>>>>>> IMHO and all that.
>>>>>>
>>>>>> --
>>>>>> /Pelle
>
>
> #|
> fredrikolofsson.com klippav.org musicalfieldsforever.com
> |#
>
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>

Re: SynthDef method cleanup

2010-02-09T06:08:27Z

hi scott, dan, fredrik,

glad you like the idea.

also, I would propose keeping the synthdef's initial function as an instvar,

or maybe in SynthDescLib by name. then one could do:

SynthDef.at(\bla).postcs

and look at the source code of the currently valid version of the synthdef

(i.e. that one last sent to the server and stored in SynthDescLib).

and one could rebuild and re-add any synthdef easily without

looking for where the source code might have been

(e.g. if the have some random decisions).

best, adc

On Feb 9, 2010, at 2:35 PM, Fredrik Olofsson wrote:

hi
my €1. there's so much confusion around all this. please let's make even more drastic changes.

make .send a very special case. sort of expert-mode. helpfile explains it's a method only useful for optimising certain code.
make .load another very special case. also expert-mode. helpfile explains about osc package size limit.
deprecate .play. it should go away. it only does harm. there's {}.play.
hide/privatise or even better remove all storing to disk. writeDef, writeDefFile, writeOnce, store, storeOnce. come on - who really needs them?

I'd be for that. one less thing to explain that can go wrong.

Dan - i don't agree with your second statement. i've never ever seen users depend on writing defs to disk. i have countless times seen users confused (myself included) by old defs loaded from disk. not to mention the file privilege installation issues for admins installing sc etc.

agree with fredrik here:

I think relying on some old file lying somewhere that has a synthdef you wrote 6 months ago to still be there,

and not having been accidentally overwrotten by a new synthdef with the same name is asking for trouble,

and should be discouraged.

the rule should be: if you rely on something to be there, please put it in your startup files.

and for completeness, when you boot a server, send it all the synthdefs currently in the Lib,

so it can "just work". that is even safer to keep things in sync than reading from disk.

thanks for the discussion! it will be great when all this synthdef mystery is gone ;-)

best, adc

Re: SynthDef method cleanup

2010-02-09T05:35:22Z

hi
my €1. there's so much confusion around all this. please let's make
even more drastic changes.

make .send a very special case. sort of expert-mode. helpfile
explains it's a method only useful for optimising certain code.
make .load another very special case. also expert-mode. helpfile
explains about osc package size limit.
deprecate .play. it should go away. it only does harm. there's
{}.play.
hide/privatise or even better remove all storing to disk. writeDef,
writeDefFile, writeOnce, store, storeOnce. come on - who really needs
them?

Dan - i don't agree with your second statement. i've never ever seen
users depend on writing defs to disk. i have countless times seen
users confused (myself included) by old defs loaded from disk. not to
mention the file privilege installation issues for admins installing
sc etc.

_f

9 feb 2010 kl. 14.17 skrev Dan Stowell:

> Yes I think .add is good. We *do* need to be harsh about deprecating,
> otherwise there's a risk we add one more method and all the others
> carry on in use, so we would have added to the complexity rather than
> reduced it!
>
>
>>> when is it _really_ necessary to store to disk?
>
> When you write a SynthDef one day and expect it to be there in future,
> without having to re-run the code every time you launch sc.
>
> Dan
>
>
>
> 2010/2/9 Scott Wilson <[hidden email]>:
>> Actually given the arguments on semantics, I think I agree with this
>> approach.
>>
>> I'd say add 'add', change all general examples to use it, and
>> deprecate
>> memStore.
>>
>> Perhaps we should publish some guidelines for method names.
>>
>> S.
>>
>> On 9 Feb 2010, at 10:55, adc wrote:
>>
>>> hi,
>>>
>>> one opinion:
>>>
>>> I think by default SynthDefs should just work as Synths and in
>>> patterns;
>>> so they should by default go to the server and the SynthDescLib.
>>> the clearest name I'v heard so far is:
>>>
>>> SynthDef(\bla, { ... }).add; // = current memStore
>>>
>>> If one does not want synthdefs in the lib (e.g. for efficiency
>>> optimisation),
>>> one could do :
>>>
>>> SynthDef(\bla, { ... }).send; // send to all running servers by
>>> default,
>>> unless server is given.
>>>
>>> To remove a synthdef, the clearest so far:
>>>
>>> SynthDef.remove(\bla); // clear it from SynthDescLib and from all
>>> running
>>> servers
>>> ( for symmetry, one could also provide : SynthDef.add(\bla,
>>> { ... });
>>> )
>>>
>>> Users should not have to worry about keeping in sync what the
>>> server knows
>>> and
>>> what synthdesclib knows. this would reduce beginners confusion a
>>> lot IMO.
>>>
>>>
>>> when is it _really_ necessary to store to disk?
>>>
>>> I sometimes find it puzzling that synthdefs that still lie around
>>> on disk
>>> get loaded on the server, so the server knows them, and they seem
>>> to work,
>>> but then, not having made them from code in the lang, patterns
>>> dont work.
>>>
>>> not storing to disk by default (unless explicitly forced) would
>>> remove
>>> that puzzle:
>>> when they are not there, they are not there.
>>>
>>> that would require touching up a lot of Synthdef code, but that
>>> code would
>>> get really simpler.
>>>
>>> just 2c,
>>> best, adc
>>>
>>>
>>> On Feb 9, 2010, at 11:26 AM, Julian Rohrhuber wrote:
>>>
>>>> Thank you for your comments. Much worse than flags are method and
>>>> argument names that center on implementation instead of behavior.
>>>> "memStore"
>>>> is a border case in a sense. What I find is that we desperately
>>>> need is a
>>>> more abstract method whose name does not reflect how a SynthDef
>>>> is made
>>>> accessible as to make it work, but clearly says that it does so.
>>>> As it is
>>>> the most common thing, it should be clear and short. While
>>>> memStore sticks
>>>> once one has learned it, it is not a nice thing to have in the
>>>> code - its
>>>> name has nothing to do with why we use it really.
>>>>
>>>> One possibility would be to make store like "memStore" by
>>>> default, and
>>>> add diskStore. Flags in the class variables may be useful, but of
>>>> course are
>>>> ugly if you need a functionality only once. But well, let's hear
>>>> some more
>>>> opinions.. :)
>>>>
>>>>
>>>> On 09.02.2010, at 07:51, Pelle Nilsson wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Being only a new user still learning SC lurking on dev, I still
>>>>> can't
>>>>> resist commenting on this issue from a new user point of view:
>>>>>
>>>>> Julian Rohrhuber <[hidden email]> writes:
>>>>>
>>>>>> Some methods of SynthDef are a bit hard to read. I've tried to
>>>>>> clear
>>>>>> thing up a bit and added a flag to send which stores the
>>>>>> synthDesc
>>>>>> (see patch).
>>>>>>
>>>>>> I'm not sure what the general opinion about this is. My
>>>>>> experience is
>>>>>> that the combinatorics of methods are hard to explain and that
>>>>>> memStore is a too complicated name for a simple behaviour. To
>>>>>> understand the name, one has to understand the history of
>>>>>> supercollider. I would not be against using the method "add"
>>>>>> instead,
>>>>>> but as we are in a mess already, I tend to just make things work.
>>>>>
>>>>> It would be great to not use boolean flags here (or elsewhere).
>>>>> As a new
>>>>> user, or probably an old user reading old code later, it is
>>>>> impossible
>>>>> to read (or write) store(true), store(false), and store() and
>>>>> remember
>>>>> what they mean (and which one the last is equivalent to). I
>>>>> always use
>>>>> memStore and part of the reason is that I can remember what it
>>>>> does for
>>>>> sure. I would love if the other version was called diskStore or
>>>>> something similar.
>>>>>
>>>>> Knowing from other programming languages, trying to hide
>>>>> combinatorics
>>>>> of methods by putting several methods in the same one and using
>>>>> flags to
>>>>> select which of the hidden methods you really want to call was
>>>>> never a
>>>>> solution to the problem.
>>>>>
>>>>> As others already said, the store methods are confusing enough
>>>>> to new
>>>>> users already. It is great to hear that something is done about
>>>>> it, but
>>>>> I hope you dev guys end up agreeing on some other solution. :)
>>>>>
>>>>> IMHO and all that.
>>>>>
>>>>> --
>>>>> /Pelle

#|
fredrikolofsson.com klippav.org musicalfieldsforever.com
|#

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: SynthDef method cleanup

2010-02-09T05:17:02Z

Yes I think .add is good. We *do* need to be harsh about deprecating,
otherwise there's a risk we add one more method and all the others
carry on in use, so we would have added to the complexity rather than
reduced it!

>> when is it _really_ necessary to store to disk?

When you write a SynthDef one day and expect it to be there in future,
without having to re-run the code every time you launch sc.

Dan

2010/2/9 Scott Wilson <[hidden email]>:

> Actually given the arguments on semantics, I think I agree with this
> approach.
>
> I'd say add 'add', change all general examples to use it, and deprecate
> memStore.
>
> Perhaps we should publish some guidelines for method names.
>
> S.
>
> On 9 Feb 2010, at 10:55, adc wrote:
>
>> hi,
>>
>> one opinion:
>>
>> I think by default SynthDefs should just work as Synths and in patterns;
>> so they should by default go to the server and the SynthDescLib.
>> the clearest name I'v heard so far is:
>>
>> SynthDef(\bla, { ... }).add; // = current memStore
>>
>> If one does not want synthdefs in the lib (e.g. for efficiency
>> optimisation),
>> one could do :
>>
>> SynthDef(\bla, { ... }).send; // send to all running servers by default,
>> unless server is given.
>>
>> To remove a synthdef, the clearest so far:
>>
>> SynthDef.remove(\bla); // clear it from SynthDescLib and from all running
>> servers
>> ( for symmetry, one could also provide : SynthDef.add(\bla, { ... });
>> )
>>
>> Users should not have to worry about keeping in sync what the server knows
>> and
>> what synthdesclib knows. this would reduce beginners confusion a lot IMO.
>>
>>
>> when is it _really_ necessary to store to disk?
>>
>> I sometimes find it puzzling that synthdefs that still lie around on disk
>> get loaded on the server, so the server knows them, and they seem to work,
>> but then, not having made them from code in the lang, patterns dont work.
>>
>> not storing to disk by default (unless explicitly forced) would remove
>> that puzzle:
>> when they are not there, they are not there.
>>
>> that would require touching up a lot of Synthdef code, but that code would
>> get really simpler.
>>
>> just 2c,
>> best, adc
>>
>>
>> On Feb 9, 2010, at 11:26 AM, Julian Rohrhuber wrote:
>>
>>> Thank you for your comments. Much worse than flags are method and
>>> argument names that center on implementation instead of behavior. "memStore"
>>> is a border case in a sense. What I find is that we desperately need is a
>>> more abstract method whose name does not reflect how a SynthDef is made
>>> accessible as to make it work, but clearly says that it does so. As it is
>>> the most common thing, it should be clear and short. While memStore sticks
>>> once one has learned it, it is not a nice thing to have in the code - its
>>> name has nothing to do with why we use it really.
>>>
>>> One possibility would be to make store like "memStore" by default, and
>>> add diskStore. Flags in the class variables may be useful, but of course are
>>> ugly if you need a functionality only once. But well, let's hear some more
>>> opinions.. :)
>>>
>>>
>>> On 09.02.2010, at 07:51, Pelle Nilsson wrote:
>>>
>>>> Hi,
>>>>
>>>> Being only a new user still learning SC lurking on dev, I still can't
>>>> resist commenting on this issue from a new user point of view:
>>>>
>>>> Julian Rohrhuber <[hidden email]> writes:
>>>>
>>>>> Some methods of SynthDef are a bit hard to read. I've tried to clear
>>>>> thing up a bit and added a flag to send which stores the synthDesc
>>>>> (see patch).
>>>>>
>>>>> I'm not sure what the general opinion about this is. My experience is
>>>>> that the combinatorics of methods are hard to explain and that
>>>>> memStore is a too complicated name for a simple behaviour. To
>>>>> understand the name, one has to understand the history of
>>>>> supercollider. I would not be against using the method "add" instead,
>>>>> but as we are in a mess already, I tend to just make things work.
>>>>
>>>> It would be great to not use boolean flags here (or elsewhere). As a new
>>>> user, or probably an old user reading old code later, it is impossible
>>>> to read (or write) store(true), store(false), and store() and remember
>>>> what they mean (and which one the last is equivalent to). I always use
>>>> memStore and part of the reason is that I can remember what it does for
>>>> sure. I would love if the other version was called diskStore or
>>>> something similar.
>>>>
>>>> Knowing from other programming languages, trying to hide combinatorics
>>>> of methods by putting several methods in the same one and using flags to
>>>> select which of the hidden methods you really want to call was never a
>>>> solution to the problem.
>>>>
>>>> As others already said, the store methods are confusing enough to new
>>>> users already. It is great to hear that something is done about it, but
>>>> I hope you dev guys end up agreeing on some other solution. :)
>>>>
>>>> IMHO and all that.
>>>>
>>>> --
>>>> /Pelle
>>>>
>>>> _______________________________________________
>>>> sc-dev mailing list
>>>>
>>>> info (subscription, etc.):
>>>> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>>> 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 (subscription, etc.):
>>> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>> 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 (subscription, etc.):
>> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> 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 (subscription, etc.):
> http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>

Re: show default server?

2010-02-09T05:04:28Z

I think it's like this to support changing from the gui window. If it
defaulted to true I think it wouldn't matter.

Do we even really need a flag? s == Server.default is so pervasive in
practice that I'd be surprised if anyone would be bothered by this
change. On the contrary not having it seems to cause problems.

S.

On 9 Feb 2010, at 12:51, Julian Rohrhuber wrote:

> setters shouldn't have two args really. So I think it could be a
> flag in the class.
>
>
> On 09.02.2010, at 13:40, Scott Wilson wrote:
>
>> Is there any reason why sync_s should not default to true?
>>
>> I find this sort of construction:
>>
>> Server.default = s = Server.internal;
>>
>> very clunky and prone to order mistakes for beginners.
>>
>> S.
>>
>> On 16 May 2009, at 17:20, Alberto de Campo wrote:
>>
>>> hi all,
>>>
>>> I find the question 'which server is currently default' occurs
>>> really often,
>>> and is a regular source of confusion for students. It occurred to
>>> me that the
>>> server windows should just show that.
>>>
>>> below the diff for an attempt - ok like that?
>>> any better ideas? opinions?
>>>
>>>
>>> best, adc
>>>
>>>
>>> Index: Control/Server.sc
>>> ===================================================================
>>> --- Control/Server.sc (revision 9164)
>>> +++ Control/Server.sc (working copy)
>>> @@ -185,7 +185,7 @@
>>> }
>>>
>>> Server : Model {
>>> - classvar <>local, <>internal, <>default, <>named, <>set,
>>> <>program;
>>> + classvar <>local, <>internal, <default, <>named, <>set, <>program;
>>>
>>> var <name, <>addr, <clientID=0;
>>> var <isLocal, <inProcess, <>sendQuit, <>remoteControlled;
>>> @@ -212,6 +212,12 @@
>>>
>>> var <pid;
>>>
>>> + *default_ { |server, sync_s = false|
>>> + default = server; // sync with s?
>>> + if (sync_s, { thisProcess.interpreter.s = server });
>>> + this.all.do(_.changed(\default));
>>> + }
>>> +
>>>
>>> Index: GUI/PlusGUI/Control/ServerPlusGUI.sc
>>> ===================================================================
>>> --- GUI/PlusGUI/Control/ServerPlusGUI.sc (revision 9164)
>>> +++ GUI/PlusGUI/Control/ServerPlusGUI.sc (working copy)
>>> @@ -15,7 +15,7 @@
>>> }
>>>
>>> makeGui { arg w;
>>> - var active, booter, killer, makeDefault, running, booting,
>>> stopped, bundling;
>>> + var active, booter, killer, makeDefault, running, booting,
>>> stopped, bundling, showDefault;
>>> var recorder, scoper;
>>> var countsViews, ctlr;
>>> var dumping = false, label, gui, font, volumeNum;
>>> @@ -68,12 +68,10 @@
>>> makeDefault = gui.button.new(w, Rect(0,0, 54, 18));
>>> makeDefault.font = font;
>>> makeDefault.canFocus = false;
>>> - makeDefault.states = [["-> default", Color.black, Color.clear]];
>>> - makeDefault.action = {
>>> - thisProcess.interpreter.s = this;
>>> - Server.default = this;
>>> - };
>>> -
>>> + makeDefault.states = [["-> default", Color.black, Color.clear],
>>> ["-> default", Color.black, Color.green.alpha_(0.2)]];
>>> + makeDefault.value_((this == Server.default).binaryValue);
>>> + makeDefault.action = { Server.default_(this, true) };
>>> +
>>> //w.view.decorator.nextLine;
>>>
>>> recorder = gui.button.new(w, Rect(0,0, 66, 18));
>>> @@ -169,6 +167,7 @@
>>> window = nil;
>>> ctlr.remove;
>>> };
>>> +
>>> },{
>>> running = {
>>> active.stringColor_(Color.new255(74, 120, 74));
>>> @@ -202,6 +201,12 @@
>>> ctlr.remove;
>>> };
>>> });
>>> +
>>> + showDefault = {
>>> + "// Server.default: % - s: % // \n\n".postf(Server.default,
>>> thisProcess.interpreter.s);
>>> + makeDefault.value = (Server.default == this).binaryValue;
>>> + };
>>> +
>>> if(serverRunning,running,stopped);
>>>
>>> w.view.decorator.nextLine;
>>> @@ -288,8 +293,10 @@
>>> if (unicode == 16rF700, { slider.increment; });
>>> if (unicode == 16rF703, { slider.increment; });
>>> if (unicode == 16rF701, { slider.decrement; });
>>> - if (unicode == 16rF702, { slider.decrement; }); nil;
>>> - });
>>> + if (unicode == 16rF702, { slider.decrement; });
>>> + nil;
>>> + })
>>> + ;
>>> volController = SimpleController(volume)
>>> .put(\amp, {|changer, what, vol|
>>> {
>>> @@ -325,7 +332,9 @@
>>> .put(\cmdPeriod,{
>>> recorder.setProperty(\value,0);
>>> })
>>> - .put(\bundling, bundling);
>>> + .put(\bundling, bundling)
>>> + .put(\default, showDefault);
>>> +
>>> this.startAliveThread;
>>> }
>>> }
>>>
>>> --
>>> --
>>> Alberto de Campo
>>> Bergstrasse 59/33
>>> A-8020 Graz, Austria
>>> e-mail : [hidden email]
>>> --
>>>
>>> _______________________________________________
>>> sc-dev mailing list
>>>
>>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>> 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 (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> 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 (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: SynthDef method cleanup

2010-02-09T04:58:16Z

So we'd then leave send as it is (no flag) ?
This makes sense, lots of change to code, but a good one.

On 09.02.2010, at 13:28, Scott Wilson wrote:

> Actually given the arguments on semantics, I think I agree with this approach.
>
> I'd say add 'add', change all general examples to use it, and deprecate memStore.
>
> Perhaps we should publish some guidelines for method names.
>
> S.
>
> On 9 Feb 2010, at 10:55, adc wrote:
>
>> hi,
>>
>> one opinion:
>>
>> I think by default SynthDefs should just work as Synths and in patterns;
>> so they should by default go to the server and the SynthDescLib.
>> the clearest name I'v heard so far is:
>>
>> SynthDef(\bla, { ... }).add; // = current memStore
>>
>> If one does not want synthdefs in the lib (e.g. for efficiency optimisation),
>> one could do :
>>
>> SynthDef(\bla, { ... }).send; // send to all running servers by default, unless server is given.
>>
>> To remove a synthdef, the clearest so far:
>>
>> SynthDef.remove(\bla); // clear it from SynthDescLib and from all running servers
>> ( for symmetry, one could also provide : SynthDef.add(\bla, { ... }); )
>>
>> Users should not have to worry about keeping in sync what the server knows and
>> what synthdesclib knows. this would reduce beginners confusion a lot IMO.
>>
>>
>> when is it _really_ necessary to store to disk?
>>
>> I sometimes find it puzzling that synthdefs that still lie around on disk
>> get loaded on the server, so the server knows them, and they seem to work,
>> but then, not having made them from code in the lang, patterns dont work.
>>
>> not storing to disk by default (unless explicitly forced) would remove that puzzle:
>> when they are not there, they are not there.
>>
>> that would require touching up a lot of Synthdef code, but that code would get really simpler.
>>
>> just 2c,
>> best, adc
>>
>>
>> On Feb 9, 2010, at 11:26 AM, Julian Rohrhuber wrote:
>>
>>> Thank you for your comments. Much worse than flags are method and argument names that center on implementation instead of behavior. "memStore" is a border case in a sense. What I find is that we desperately need is a more abstract method whose name does not reflect how a SynthDef is made accessible as to make it work, but clearly says that it does so. As it is the most common thing, it should be clear and short. While memStore sticks once one has learned it, it is not a nice thing to have in the code - its name has nothing to do with why we use it really.
>>>
>>> One possibility would be to make store like "memStore" by default, and add diskStore. Flags in the class variables may be useful, but of course are ugly if you need a functionality only once. But well, let's hear some more opinions.. :)
>>>
>>>
>>> On 09.02.2010, at 07:51, Pelle Nilsson wrote:
>>>
>>>> Hi,
>>>>
>>>> Being only a new user still learning SC lurking on dev, I still can't
>>>> resist commenting on this issue from a new user point of view:
>>>>
>>>> Julian Rohrhuber <[hidden email]> writes:
>>>>
>>>>> Some methods of SynthDef are a bit hard to read. I've tried to clear
>>>>> thing up a bit and added a flag to send which stores the synthDesc
>>>>> (see patch).
>>>>>
>>>>> I'm not sure what the general opinion about this is. My experience is
>>>>> that the combinatorics of methods are hard to explain and that
>>>>> memStore is a too complicated name for a simple behaviour. To
>>>>> understand the name, one has to understand the history of
>>>>> supercollider. I would not be against using the method "add" instead,
>>>>> but as we are in a mess already, I tend to just make things work.
>>>>
>>>> It would be great to not use boolean flags here (or elsewhere). As a new
>>>> user, or probably an old user reading old code later, it is impossible
>>>> to read (or write) store(true), store(false), and store() and remember
>>>> what they mean (and which one the last is equivalent to). I always use
>>>> memStore and part of the reason is that I can remember what it does for
>>>> sure. I would love if the other version was called diskStore or
>>>> something similar.
>>>>
>>>> Knowing from other programming languages, trying to hide combinatorics
>>>> of methods by putting several methods in the same one and using flags to
>>>> select which of the hidden methods you really want to call was never a
>>>> solution to the problem.
>>>>
>>>> As others already said, the store methods are confusing enough to new
>>>> users already. It is great to hear that something is done about it, but
>>>> I hope you dev guys end up agreeing on some other solution. :)
>>>>
>>>> IMHO and all that.
>>>>
>>>> --
>>>> /Pelle
>>>>
>>>> _______________________________________________
>>>> sc-dev mailing list
>>>>
>>>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>>> 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 (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>> 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 (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> 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 (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: show default server?

2010-02-09T04:51:07Z

setters shouldn't have two args really. So I think it could be a flag in the class.

On 09.02.2010, at 13:40, Scott Wilson wrote:

> Is there any reason why sync_s should not default to true?
>
> I find this sort of construction:
>
> Server.default = s = Server.internal;
>
> very clunky and prone to order mistakes for beginners.
>
> S.
>
> On 16 May 2009, at 17:20, Alberto de Campo wrote:
>
>> hi all,
>>
>> I find the question 'which server is currently default' occurs really often,
>> and is a regular source of confusion for students. It occurred to me that the
>> server windows should just show that.
>>
>> below the diff for an attempt - ok like that?
>> any better ideas? opinions?
>>
>>
>> best, adc
>>
>>
>> Index: Control/Server.sc
>> ===================================================================
>> --- Control/Server.sc (revision 9164)
>> +++ Control/Server.sc (working copy)
>> @@ -185,7 +185,7 @@
>> }
>>
>> Server : Model {
>> - classvar <>local, <>internal, <>default, <>named, <>set, <>program;
>> + classvar <>local, <>internal, <default, <>named, <>set, <>program;
>>
>> var <name, <>addr, <clientID=0;
>> var <isLocal, <inProcess, <>sendQuit, <>remoteControlled;
>> @@ -212,6 +212,12 @@
>>
>> var <pid;
>>
>> + *default_ { |server, sync_s = false|
>> + default = server; // sync with s?
>> + if (sync_s, { thisProcess.interpreter.s = server });
>> + this.all.do(_.changed(\default));
>> + }
>> +
>>
>> Index: GUI/PlusGUI/Control/ServerPlusGUI.sc
>> ===================================================================
>> --- GUI/PlusGUI/Control/ServerPlusGUI.sc (revision 9164)
>> +++ GUI/PlusGUI/Control/ServerPlusGUI.sc (working copy)
>> @@ -15,7 +15,7 @@
>> }
>>
>> makeGui { arg w;
>> - var active, booter, killer, makeDefault, running, booting, stopped, bundling;
>> + var active, booter, killer, makeDefault, running, booting, stopped, bundling, showDefault;
>> var recorder, scoper;
>> var countsViews, ctlr;
>> var dumping = false, label, gui, font, volumeNum;
>> @@ -68,12 +68,10 @@
>> makeDefault = gui.button.new(w, Rect(0,0, 54, 18));
>> makeDefault.font = font;
>> makeDefault.canFocus = false;
>> - makeDefault.states = [["-> default", Color.black, Color.clear]];
>> - makeDefault.action = {
>> - thisProcess.interpreter.s = this;
>> - Server.default = this;
>> - };
>> -
>> + makeDefault.states = [["-> default", Color.black, Color.clear], ["-> default", Color.black, Color.green.alpha_(0.2)]];
>> + makeDefault.value_((this == Server.default).binaryValue);
>> + makeDefault.action = { Server.default_(this, true) };
>> +
>> //w.view.decorator.nextLine;
>>
>> recorder = gui.button.new(w, Rect(0,0, 66, 18));
>> @@ -169,6 +167,7 @@
>> window = nil;
>> ctlr.remove;
>> };
>> +
>> },{
>> running = {
>> active.stringColor_(Color.new255(74, 120, 74));
>> @@ -202,6 +201,12 @@
>> ctlr.remove;
>> };
>> });
>> +
>> + showDefault = {
>> + "// Server.default: % - s: % // \n\n".postf(Server.default, thisProcess.interpreter.s);
>> + makeDefault.value = (Server.default == this).binaryValue;
>> + };
>> +
>> if(serverRunning,running,stopped);
>>
>> w.view.decorator.nextLine;
>> @@ -288,8 +293,10 @@
>> if (unicode == 16rF700, { slider.increment; });
>> if (unicode == 16rF703, { slider.increment; });
>> if (unicode == 16rF701, { slider.decrement; });
>> - if (unicode == 16rF702, { slider.decrement; }); nil;
>> - });
>> + if (unicode == 16rF702, { slider.decrement; });
>> + nil;
>> + })
>> + ;
>> volController = SimpleController(volume)
>> .put(\amp, {|changer, what, vol|
>> {
>> @@ -325,7 +332,9 @@
>> .put(\cmdPeriod,{
>> recorder.setProperty(\value,0);
>> })
>> - .put(\bundling, bundling);
>> + .put(\bundling, bundling)
>> + .put(\default, showDefault);
>> +
>> this.startAliveThread;
>> }
>> }
>>
>> --
>> --
>> Alberto de Campo
>> Bergstrasse 59/33
>> A-8020 Graz, Austria
>> e-mail : [hidden email]
>> --
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> 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 (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: show default server?

2010-02-09T04:40:33Z

Is there any reason why sync_s should not default to true?

I find this sort of construction:

Server.default = s = Server.internal;

very clunky and prone to order mistakes for beginners.

S.

On 16 May 2009, at 17:20, Alberto de Campo wrote:

> hi all,
>
> I find the question 'which server is currently default' occurs
> really often,
> and is a regular source of confusion for students. It occurred to me
> that the
> server windows should just show that.
>
> below the diff for an attempt - ok like that?
> any better ideas? opinions?
>
>
> best, adc
>
>
> Index: Control/Server.sc
> ===================================================================
> --- Control/Server.sc (revision 9164)
> +++ Control/Server.sc (working copy)
> @@ -185,7 +185,7 @@
> }
>
> Server : Model {
> - classvar <>local, <>internal, <>default, <>named, <>set, <>program;
> + classvar <>local, <>internal, <default, <>named, <>set, <>program;
>
> var <name, <>addr, <clientID=0;
> var <isLocal, <inProcess, <>sendQuit, <>remoteControlled;
> @@ -212,6 +212,12 @@
>
> var <pid;
>
> + *default_ { |server, sync_s = false|
> + default = server; // sync with s?
> + if (sync_s, { thisProcess.interpreter.s = server });
> + this.all.do(_.changed(\default));
> + }
> +
>
> Index: GUI/PlusGUI/Control/ServerPlusGUI.sc
> ===================================================================
> --- GUI/PlusGUI/Control/ServerPlusGUI.sc (revision 9164)
> +++ GUI/PlusGUI/Control/ServerPlusGUI.sc (working copy)
> @@ -15,7 +15,7 @@
> }
>
> makeGui { arg w;
> - var active, booter, killer, makeDefault, running, booting,
> stopped, bundling;
> + var active, booter, killer, makeDefault, running, booting,
> stopped, bundling, showDefault;
> var recorder, scoper;
> var countsViews, ctlr;
> var dumping = false, label, gui, font, volumeNum;
> @@ -68,12 +68,10 @@
> makeDefault = gui.button.new(w, Rect(0,0, 54, 18));
> makeDefault.font = font;
> makeDefault.canFocus = false;
> - makeDefault.states = [["-> default", Color.black, Color.clear]];
> - makeDefault.action = {
> - thisProcess.interpreter.s = this;
> - Server.default = this;
> - };
> -
> + makeDefault.states = [["-> default", Color.black, Color.clear],
> ["-> default", Color.black, Color.green.alpha_(0.2)]];
> + makeDefault.value_((this == Server.default).binaryValue);
> + makeDefault.action = { Server.default_(this, true) };
> +
> //w.view.decorator.nextLine;
>
> recorder = gui.button.new(w, Rect(0,0, 66, 18));
> @@ -169,6 +167,7 @@
> window = nil;
> ctlr.remove;
> };
> +
> },{
> running = {
> active.stringColor_(Color.new255(74, 120, 74));
> @@ -202,6 +201,12 @@
> ctlr.remove;
> };
> });
> +
> + showDefault = {
> + "// Server.default: % - s: % // \n\n".postf(Server.default,
> thisProcess.interpreter.s);
> + makeDefault.value = (Server.default == this).binaryValue;
> + };
> +
> if(serverRunning,running,stopped);
>
> w.view.decorator.nextLine;
> @@ -288,8 +293,10 @@
> if (unicode == 16rF700, { slider.increment; });
> if (unicode == 16rF703, { slider.increment; });
> if (unicode == 16rF701, { slider.decrement; });
> - if (unicode == 16rF702, { slider.decrement; }); nil;
> - });
> + if (unicode == 16rF702, { slider.decrement; });
> + nil;
> + })
> + ;
> volController = SimpleController(volume)
> .put(\amp, {|changer, what, vol|
> {
> @@ -325,7 +332,9 @@
> .put(\cmdPeriod,{
> recorder.setProperty(\value,0);
> })
> - .put(\bundling, bundling);
> + .put(\bundling, bundling)
> + .put(\default, showDefault);
> +
> this.startAliveThread;
> }
> }
>
> --
> --
> Alberto de Campo
> Bergstrasse 59/33
> A-8020 Graz, Austria
> e-mail : [hidden email]
> --
>
> _______________________________________________
> sc-dev mailing list
>
> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

NumberBox scrolling fix

2010-02-09T04:38:55Z

hi, i always swore i'd never (deliberately) post to the dev list, but where i have come across a specific problem and can submit a solution that is easy to implement and does not break code, then i may as well post it here. if this is somehow unacceptable, then... what is this list for!

so, i have had problems with the scrolling behaviour of NumberBox. i am on osx so i am specifically referencing SCNumberBox. i don't understand how it can be regarded as usable behaviour if the scrolling is both horizontal and vertical at the same time. i am used to scrolling vertically, as was the case in sc1 and sc2 so i got used to it as a matter of preference, anyway so if i scroll vertically upwards but my mouse wavers even one horizontal pixel backwards, the value will start going the other way, and the resulting value jumps all over the place. i think it's better to have either horizontal or vertical scrolling, and personally i would have vertical only scrolling as the default. however, since i want to avoid the inevitable moans of "that will break code!" the following solution preserves the current behaviour, unless scrollDirection is specifically set to one thing or the other. i used /h and /v as that's what Gradient does.

so in the variable declarations, add:

var <>scrollDirection;

and then alter mouseMove as follows:

mouseMove { arg x, y, modifiers;

var direction;

if (scroll == true, {

case

{scrollDirection == \h}

{

// horizontal scrolling:

if ((x - hit.x) < 0) {direction = -1.0} {direction = 1.0};

}

{scrollDirection == \v}

{

// vertical scrolling:

if ((y - hit.y) > 0) {direction = -1.0} {direction = 1.0};

}

{

// horizontal or vertical scrolling:

direction = 1.0;

if ( (x - hit.x) < 0 or: { (y - hit.y) > 0 }) { direction = -1.0; };

};

this.valueAction = (this.value + (inc * this.scroll_step * direction));

hit = Point(x, y);

});

mouseMoveAction.value(this, x, y, modifiers);

}

then one can do this:

b = NumberBox(w, Rect(150, 10, 100, 20));

b.scrollDirection_(\v);

i would appreciate very much this receiving your consideration, thanks.

Re: SynthDef method cleanup

2010-02-09T04:28:03Z

Actually given the arguments on semantics, I think I agree with this
approach.

I'd say add 'add', change all general examples to use it, and
deprecate memStore.

Perhaps we should publish some guidelines for method names.

S.

On 9 Feb 2010, at 10:55, adc wrote:

> hi,
>
> one opinion:
>
> I think by default SynthDefs should just work as Synths and in
> patterns;
> so they should by default go to the server and the SynthDescLib.
> the clearest name I'v heard so far is:
>
> SynthDef(\bla, { ... }).add; // = current memStore
>
> If one does not want synthdefs in the lib (e.g. for efficiency
> optimisation),
> one could do :
>
> SynthDef(\bla, { ... }).send; // send to all running servers by
> default, unless server is given.
>
> To remove a synthdef, the clearest so far:
>
> SynthDef.remove(\bla); // clear it from SynthDescLib and from all
> running servers
> ( for symmetry, one could also provide : SynthDef.add(\bla,
> { ... }); )
>
> Users should not have to worry about keeping in sync what the server
> knows and
> what synthdesclib knows. this would reduce beginners confusion a lot
> IMO.
>
>
> when is it _really_ necessary to store to disk?
>
> I sometimes find it puzzling that synthdefs that still lie around on
> disk
> get loaded on the server, so the server knows them, and they seem to
> work,
> but then, not having made them from code in the lang, patterns dont
> work.
>
> not storing to disk by default (unless explicitly forced) would
> remove that puzzle:
> when they are not there, they are not there.
>
> that would require touching up a lot of Synthdef code, but that code
> would get really simpler.
>
> just 2c,
> best, adc
>
>
> On Feb 9, 2010, at 11:26 AM, Julian Rohrhuber wrote:
>
>> Thank you for your comments. Much worse than flags are method and
>> argument names that center on implementation instead of behavior.
>> "memStore" is a border case in a sense. What I find is that we
>> desperately need is a more abstract method whose name does not
>> reflect how a SynthDef is made accessible as to make it work, but
>> clearly says that it does so. As it is the most common thing, it
>> should be clear and short. While memStore sticks once one has
>> learned it, it is not a nice thing to have in the code - its name
>> has nothing to do with why we use it really.
>>
>> One possibility would be to make store like "memStore" by default,
>> and add diskStore. Flags in the class variables may be useful, but
>> of course are ugly if you need a functionality only once. But well,
>> let's hear some more opinions.. :)
>>
>>
>> On 09.02.2010, at 07:51, Pelle Nilsson wrote:
>>
>>> Hi,
>>>
>>> Being only a new user still learning SC lurking on dev, I still
>>> can't
>>> resist commenting on this issue from a new user point of view:
>>>
>>> Julian Rohrhuber <[hidden email]> writes:
>>>
>>>> Some methods of SynthDef are a bit hard to read. I've tried to
>>>> clear
>>>> thing up a bit and added a flag to send which stores the synthDesc
>>>> (see patch).
>>>>
>>>> I'm not sure what the general opinion about this is. My
>>>> experience is
>>>> that the combinatorics of methods are hard to explain and that
>>>> memStore is a too complicated name for a simple behaviour. To
>>>> understand the name, one has to understand the history of
>>>> supercollider. I would not be against using the method "add"
>>>> instead,
>>>> but as we are in a mess already, I tend to just make things work.
>>>
>>> It would be great to not use boolean flags here (or elsewhere). As
>>> a new
>>> user, or probably an old user reading old code later, it is
>>> impossible
>>> to read (or write) store(true), store(false), and store() and
>>> remember
>>> what they mean (and which one the last is equivalent to). I always
>>> use
>>> memStore and part of the reason is that I can remember what it
>>> does for
>>> sure. I would love if the other version was called diskStore or
>>> something similar.
>>>
>>> Knowing from other programming languages, trying to hide
>>> combinatorics
>>> of methods by putting several methods in the same one and using
>>> flags to
>>> select which of the hidden methods you really want to call was
>>> never a
>>> solution to the problem.
>>>
>>> As others already said, the store methods are confusing enough to
>>> new
>>> users already. It is great to hear that something is done about
>>> it, but
>>> I hope you dev guys end up agreeing on some other solution. :)
>>>
>>> IMHO and all that.
>>>
>>> --
>>> /Pelle
>>>
>>> _______________________________________________
>>> sc-dev mailing list
>>>
>>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>>> 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 (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> 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 (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: The Plot. (was plotting behaviour) : Quark or Common?

2010-02-09T04:19:54Z

Hi Ron,

just to be sure, I've attached a new version that has a few fixes (renamed MultiPlot to Plotter). I think it does what you intend, but let's see.

On 09.02.2010, at 13:09, ronald kuivila wrote:

> var <>overlap;
>
> updatePlotBounds {
> var deltaY = if(this.numChannels > 1 ) { gapY } { 0.0 };
> var distY = bounds.height / this.numChannels;
> var height = max(20, distY - deltaY);
> var min, max;
>
> if (overlap) {
> plotViews.do { |view, i|
> view.bounds_(bounds)
> };
> plotViews[1..].do{ | pv | pv.backgroundColor.alpha_(0) };
>
> min = plotViews.collect { | v | v.spec.minval }.minItem;
> max = plotViews.collect { | v | v.spec.maxval }.maxItem;
> plotViews.do { | v | v.spec.minval_(min); v.spec.maxval_(max) };
> }{
> plotViews.do { |view, i|
> view.bounds_(
> Rect(bounds.left, distY * i + bounds.top, bounds.width, height)
> )
> };
> }
> }
> }

PlotView.sc (13K) Download Attachment
PlotWindow.scd (2K) Download Attachment

supernova v0.2

2010-02-09T04:10:24Z

hi all,

there is a new release of supernova, a multi-processor aware version of
the supercollider server scsynth. it provides most features of scsynth,
the most prominent feature, that is still missing, is non-realtime
synthesis. that will be part of v0.3, though ...

getting started:
http://tim.klingt.org/code/wiki/supernova

tarballs: http://tim.klingt.org/code/projects/list_files/supernova
git repository: git://tim.klingt.org/supercollider.git
debs: https://launchpad.net/~tim-klingt/+archive/supernova

cheers, tim

--
[hidden email]
http://tim.klingt.org

Happiness is a byproduct of function, purpose, and conflict; those who
seek happiness for itself seek victory without war.
William S. Burroughs

signature.asc (204 bytes) Download Attachment

Re: The Plot. (was plotting behaviour) : Quark or Common?

2010-02-09T04:09:57Z

HI Julian,

I don't see what you mean here. Trying x.flop.bubble.plot2 I get an error.

One could always go x.flop.flat.plot, but that does not give the picture you want.

Here is a hack that does what I was suggesting:

+MultiPlot {

var <>overlap;

updatePlotBounds {

var deltaY = if(this.numChannels > 1 ) { gapY } { 0.0 };

var distY = bounds.height / this.numChannels;

var height = max(20, distY - deltaY);

var min, max;

if (overlap) {

plotViews.do { |view, i|

view.bounds_(bounds)

};

plotViews[1..].do{ | pv | pv.backgroundColor.alpha_(0) };

min = plotViews.collect { | v | v.spec.minval }.minItem;

max = plotViews.collect { | v | v.spec.maxval }.maxItem;

plotViews.do { | v | v.spec.minval_(min); v.spec.maxval_(max) };

}{

plotViews.do { |view, i|

view.bounds_(

Rect(bounds.left, distY * i + bounds.top, bounds.width, height)

)

};

}

+ ArrayedCollection {

plot2 { arg name, bounds, discrete=false, numChannels, minval, maxval, overlap = false;

var array = this.as(Array), res = PlotWindow(name, bounds);

res.multiPlot.overlap_(overlap);

if(discrete) { res.plotMode = \points };

numChannels !? { array = array.unlace(numChannels) };

res.value = array;

minval !? { res.multiPlot.minval = minval };

maxval !? { res.multiPlot.maxval = maxval };

^res.front

}

SF.net SVN: quarks:[1372] JITMIDIKtl

2010-02-09T03:05:19Z

Revision: 1372
http://quarks.svn.sourceforge.net/quarks/?rev=1372&view=rev
Author: decampo
Date: 2010-02-09 11:05:19 +0000 (Tue, 09 Feb 2010)

Log Message:
-----------
added pocketdial class, more cleanups.

Modified Paths:
--------------
JITMIDIKtl/BCRKtl.sc
JITMIDIKtl/FFLV2Ktl.sc
JITMIDIKtl/MIDIKtl.sc
JITMIDIKtl/NanoKtl.html
JITMIDIKtl/NanoKtl.sc
JITMIDIKtl/PFKtl.sc

Added Paths:
-----------
JITMIDIKtl/PDKtl.html

Modified: JITMIDIKtl/BCRKtl.sc
===================================================================
--- JITMIDIKtl/BCRKtl.sc 2010-02-07 20:50:55 UTC (rev 1371)
+++ JITMIDIKtl/BCRKtl.sc 2010-02-09 11:05:19 UTC (rev 1372)
@@ -10,17 +10,6 @@
this.makeDefaults;
}

- init {
- super.init;
- ctlNames = defaults[this.class];
- ^this
- }
-
- mapCC { |ctl= \sl1, action|
- var ccDictKey = ctlNames[ctl]; // '0_42'
- ccDict.put(ccDictKey, action);
- }
-
mapToPxPars { |proxy ... pairs|
if (midiOut.notNil) {
this.sendFromProxy(proxy, pairs);

Modified: JITMIDIKtl/FFLV2Ktl.sc
===================================================================
--- JITMIDIKtl/FFLV2Ktl.sc 2010-02-07 20:50:55 UTC (rev 1371)
+++ JITMIDIKtl/FFLV2Ktl.sc 2010-02-09 11:05:19 UTC (rev 1372)
@@ -6,15 +6,9 @@

init {
super.init;
- ctlNames = defaults[this.class];
lastVals = ();
}

- mapCC { |ctl= \sl1, action|
- var ccDictKey = ctlNames[ctl]; // '0_42'
- ccDict.put(ccDictKey, action);
- }
-
// to do: how to map to editor?

// how to map to proxymixer?

Modified: JITMIDIKtl/MIDIKtl.sc
===================================================================
--- JITMIDIKtl/MIDIKtl.sc 2010-02-07 20:50:55 UTC (rev 1371)
+++ JITMIDIKtl/MIDIKtl.sc 2010-02-09 11:05:19 UTC (rev 1372)
@@ -14,6 +14,8 @@
// subclasses override this method.
// they put their controller keys and chan/ccnum combinations into
// defaults[class]
+ // MIDIKtl is empty by default
+ defaults.put(this.class, ());
}

*new { |srcID, ccDict, noteDict|
@@ -27,6 +29,8 @@
}

init {
+ ctlNames = defaults[this.class];
+
ccDict = ccDict ?? ();

ccresp.remove;
@@ -49,7 +53,34 @@
}

noteKeyToChanNote { |noteKey| ^noteKey.asString.split($_).asInteger }
+
+ // use when ctlNames is one flat dict
+ mapCC { |ctl= \sl1, action|
+ var ccDictKey = ctlNames[ctl]; // '0_42'
+ if (ccDictKey.isNil) {
+ warn("key % : no chan_ccnum found!\n".format(ctl));
+ ^this
+ };
+ ccDict.put(ccDictKey, action);
+ }

+ // use when ctlNames are scene-based dicts (NanoKtl, PDKtl)
+ mapCCS { |scene=2, ctl= \sl1, action|
+ var ccScene, ccDictKey;
+
+ ccScene = ctlNames[scene];
+ if (ccScene.isNil) {
+ warn("% : mapCCS: scene % : not found!\n".format(this, scene));
+ ^this
+ };
+ ccDictKey = ccScene[ctl]; // '0_42'
+ if (ccDictKey.isNil) {
+ warn("key % : no chan_ccnum found!\n".format(ctl));
+ ^nil
+ };
+ ccDict.put(ccDictKey, action);
+ }
+
}

MIDINKtl : MIDIKtl {
@@ -80,6 +111,15 @@
}, srcID);
}

+ mapNoteOn {
+
+ }
+
+ mapNoteOff {
+
+ }
+
+
free {
super.free;

Modified: JITMIDIKtl/NanoKtl.html
===================================================================
--- JITMIDIKtl/NanoKtl.html 2010-02-07 20:50:55 UTC (rev 1371)
+++ JITMIDIKtl/NanoKtl.html 2010-02-09 11:05:19 UTC (rev 1372)
@@ -91,8 +91,8 @@
 g.ccresp; // a midi CCResponder listing to that MIDI port
 
 // map transport buttons 'play' and 'rec' to simple actions: 
- g.mapCC(0, 'play', { |ch, cc, val| " 'play': %.\n".postf([ch, cc, val]) });
- g.mapCC(0, 'rec', { |ch, cc, val| " 'rec': %.\n".postf([ch, cc, val]) });
+ g.mapCCS(0, 'play', { |ch, cc, val| " 'play': %.\n".postf([ch, cc, val]) });
+ g.mapCCS(0, 'rec', { |ch, cc, val| " 'rec': %.\n".postf([ch, cc, val]) });
 // the actions are now in the dict:
 g.ccDict.postcs;
 
@@ -120,24 +120,24 @@
 g.ctlNames[1]
 
 // add some more mapped actions
- g.mapCC(1, 'sl1', { |ch, cc, val| " scene 1, slider1: %.\n".postf([ch, cc, val]) });
- g.mapCC(1, 'kn2', { |ch, cc, val| " scene 1, knob2: %.\n".postf([ch, cc, val]) });
- g.mapCC(1, 'bu3', { |ch, cc, val| " scene 1, button up 3: %.\n".postf([ch, cc, val]) });
- g.mapCC(1, 'bd3', { |ch, cc, val| " scene 1, button down 3: %.\n".postf([ch, cc, val]) });
+ g.mapCCS(1, 'sl1', { |ch, cc, val| " scene 1, slider1: %.\n".postf([ch, cc, val]) });
+ g.mapCCS(1, 'kn2', { |ch, cc, val| " scene 1, knob2: %.\n".postf([ch, cc, val]) });
+ g.mapCCS(1, 'bu3', { |ch, cc, val| " scene 1, button up 3: %.\n".postf([ch, cc, val]) });
+ g.mapCCS(1, 'bd3', { |ch, cc, val| " scene 1, button down 3: %.\n".postf([ch, cc, val]) });
 
 g.ccDict;
 
Instance Methods
 
- mapCC (editor, scene)
+ mapCCS (editor, scene)
 
 map one of the controls in a scene to a general function.
 
 g = NanoKtl.new; // listen to all midi in ports
- g.mapCC(1, 'sl1', { |ch, cc, val| " scene 1, slider1: %.\n".postf([ch, cc, val]) });
- g.mapCC(1, 'kn2', { |ch, cc, val| " scene 1, knob2: %.\n".postf([ch, cc, val]) });
- g.mapCC(1, 'bu3', { |ch, cc, val| " scene 1, button up 3: %.\n".postf([ch, cc, val]) });
- g.mapCC(1, 'bd3', { |ch, cc, val| " scene 1, button down 3: %.\n".postf([ch, cc, val]) });
+ g.mapCCS(1, 'sl1', { |ch, cc, val| " scene 1, slider1: %.\n".postf([ch, cc, val]) });
+ g.mapCCS(1, 'kn2', { |ch, cc, val| " scene 1, knob2: %.\n".postf([ch, cc, val]) });
+ g.mapCCS(1, 'bu3', { |ch, cc, val| " scene 1, button up 3: %.\n".postf([ch, cc, val]) });
+ g.mapCCS(1, 'bd3', { |ch, cc, val| " scene 1, button down 3: %.\n".postf([ch, cc, val]) });
 g.ccDict;
 
 mapToPxEdit (editor, scene)

Modified: JITMIDIKtl/NanoKtl.sc
===================================================================
--- JITMIDIKtl/NanoKtl.sc 2010-02-07 20:50:55 UTC (rev 1371)
+++ JITMIDIKtl/NanoKtl.sc 2010-02-09 11:05:19 UTC (rev 1372)
@@ -29,11 +29,6 @@

^this
}
-
- mapCC { |scene=2, ctl= \sl1, action|
- var ccDictKey = ctlNames[scene][ctl]; // '0_42'
- ccDict.put(ccDictKey, action);
- }

mapToPxEdit { |editor, scene=1, volPause = true|
pxEditors.put(scene, editor);
@@ -41,7 +36,7 @@
// map 8 knobs to params - can be shifted
[\kn1, \kn2, \kn3, \kn4, \kn5, \kn6, \kn7, \kn8].do { |key, i|

- this.mapCC(scene, key,
+ this.mapCCS(scene, key,
{ |ch, cc, val|
var proxy = pxEditors[scene].proxy;
var parKey = pxEditors[scene].editKeys[i + parOffsets[scene]];
@@ -55,7 +50,7 @@
)
};
// and use 9th knob for proxy volume
- this.mapCC(scene, \kn9, { |ch, cc, val|
+ this.mapCCS(scene, \kn9, { |ch, cc, val|
var lastVal = lastVals[\kn9];
var mappedVol = \amp.asSpec.map(val / 127);
var proxy = pxEditors[scene].proxy;
@@ -71,7 +66,7 @@
pairs.do { |pair|
var ctlName, paramName;
#ctlName, paramName = pair;
- this.mapCC(scene, ctlName,
+ this.mapCCS(scene, ctlName,
{ |ch, cc, midival|
proxy.set(paramName, paramName.asSpec.map(midival / 127))
}
@@ -92,13 +87,13 @@
mastaFunc = { |chan, cc, val| server.volume.volume_(\mastaVol.asSpec.map(val/127)) };

Spec.add(\mastaVol, [server.volume.min, server.volume.max, \db]);
- (1..4).do { |scene| this.mapCC(scene, \sl9, mastaFunc) };
+ (1..4).do { |scene| this.mapCCS(scene, \sl9, mastaFunc) };

// scene 1:

// map first 8 volumes to sliders
[\sl1, \sl2, \sl3, \sl4, \sl5, \sl6, \sl7, \sl8].do { |key, i|
- this.mapCC(scene, key,
+ this.mapCCS(scene, key,
{ |ch, cc, val|
var lastVal = lastVals[key];
var mappedVal = \amp.asSpec.map(val / 127);
@@ -116,13 +111,13 @@
};
// upper buttons: send to editor
[\bu1, \bu2, \bu3, \bu4, \bu5, \bu6, \bu7, \bu8].do { |key, i|
- this.mapCC(scene, key,
+ this.mapCCS(scene, key,
{ |ch, cc, val| defer { pxmixers[scene].editBtnsAr[i + pxOffsets[scene]].doAction }; })
};

// lower buttons: toggle play/stop
[\bd1, \bd2, \bd3, \bd4, \bd5, \bd6, \bd7, \bd8].do { |key, i|
- this.mapCC(scene, key,
+ this.mapCCS(scene, key,
{ |ch, cc, val| defer {
var px = pxmixers[scene].pxMons[i + pxOffsets[scene]].proxy;
if ( ctlNames[scene]['mode'] == 'push' ){
@@ -138,8 +133,8 @@
}; )
};

- this.mapCC(scene, \bu9, { |src, chan, val| if (val > 0) { this.pxShift(1, scene) } });
- this.mapCC(scene, \bd9, { |src, chan, val| if (val > 0) { this.paramShift(1, scene) } });
+ this.mapCCS(scene, \bu9, { |src, chan, val| if (val > 0) { this.pxShift(1, scene) } });
+ this.mapCCS(scene, \bd9, { |src, chan, val| if (val > 0) { this.paramShift(1, scene) } });

this.pxShift(0, scene);
this.mapToPxEdit(mixer.editor, scene);
Added: JITMIDIKtl/PDKtl.html
===================================================================
--- JITMIDIKtl/PDKtl.html (rev 0)
+++ JITMIDIKtl/PDKtl.html 2010-02-09 11:05:19 UTC (rev 1372)
@@ -0,0 +1,127 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<meta http-equiv="Content-Style-Type" content="text/css">
+<title></title>
+<meta name="Generator" content="Cocoa HTML Writer">
+<meta name="CocoaVersion" content="1038.25">
+<style type="text/css">
+p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica}
+p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px}
+p.p3 {margin: 0.0px 0.0px 0.0px 0.0px; font: 9.0px Monaco; min-height: 12.0px}
+p.p4 {margin: 0.0px 0.0px 0.0px 0.0px; font: 9.0px Monaco}
+p.p5 {margin: 0.0px 0.0px 0.0px 0.0px; font: 9.0px Monaco; color: #cd0b0b}
+p.p6 {margin: 0.0px 0.0px 0.0px 0.0px; font: 9.0px Monaco; color: #2024c7}
+p.p7 {margin: 0.0px 0.0px 0.0px 0.0px; font: 9.0px Monaco; color: #737373}
+p.p8 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; color: #2b30fa; min-height: 14.0px}
+p.p9 {margin: 0.0px 0.0px 0.0px 0.0px; font: 9.0px Monaco; color: #ad140d}
+span.s1 {font: 18.0px Helvetica}
+span.s2 {font: 9.0px Monaco}
+span.s3 {font: 12.0px Helvetica; color: #2b30fa}
+span.s4 {color: #0000ee}
+span.s5 {color: #2b30fa}
+span.s6 {text-decoration: underline ; color: #2b30fa}
+span.s7 {color: #000000}
+span.s8 {color: #008417}
+span.s9 {color: #737373}
+span.s10 {color: #2024c7}
+span.s11 {color: #1d20b9}
+span.s12 {color: #606060}
+span.s13 {color: #ad140d}
+span.Apple-tab-span {white-space:pre}
+</style>
+</head>
+<body>
+PDKtl a MIDIKtl class for the Doepfer PocketDial
+ 
+The Doepfer PocketDial only has 16 endless knobs, so PDKtl is a rather simple class. 
+ 
+ 
+see also <a href="PFKtl.html">PFKtl</a>, <a href="MIDIKtl.html">MIDIKtl</a>, NanoKtl
+ 
+first example
+ 
+ // make a new PDKtl
+f = PDKtl.new;
+ 
+ // map a single slider's action
+f.mapCC(\kn01, { |chan, ccnum, val| 
+ var normstep = 0.01; 
+ var midiNudge = 64 - val; 
+ var normedNudge = midiNudge * normstep;
+ "PDKtl test: ch % cc % val % - midinudge: % normedNudge: % \n"
+ .postf(chan, ccnum, val, midiNudge, normedNudge);
+ "map here with a spec..." 
+}); 
+ 
+ // fails if no midi info for that key
+f.mapCC(\wrongKey, { |chan, ccnum, val| "PDKtl test: ch % cc % val %\n".postf(chan, ccnum, val) }); 
+ 
+ 
+Class Variables
+ *verbose // a flag whether the class posts extended info 
+ 
+ PDKtl.verbose = true;
+ PDKtl.verbose = false;
+ 
+Instance Variables
+ 
+Methods
+ 
+ *new(uid) make a new PDKtl. uid is an optional ID for the MIDI port to listen to. 
+ 
+f = PDKtl.new;
+ 
+ mapCCS(scene, ctl, action)
+ 
+ // map a single knob's action
+f.mapCCS(1, \kn01, { |chan, ccnum, val| "PDKtl test: ch % cc % val %\n".postf(chan, ccnum, val) }); 
+ 
+ // the valid names are:
+f.ctlNames[1].keys.asArray.sort;
+ 
+ 
+ mapToPxEdit(editor, indices, lastIsVol) - map to a NodeProxyEditor.
+ editor the editor
+ indices which sliders to map to. default is [1, 2 .. 8]. 
+ lastIsVol flag whether the last slider becomes a volume control for that editor.
+ 
+ 
+( // make an Ndef and its editor first
+Spec.add(\harm, [2, 200, \exp]);
+Ndef(\a, { |freq = 20, harm = 20| Blip.ar(freq, harm) });
+o = NodeProxyEditor(Ndef(\a));
+ 
+f.mapToPxEdit(o, 1);
+)
+ 
+ mapToPxMix(mixer, splitIndex, lastEdIsVol, lastIsMaster) map to a proxymixer. 
+ 
+ mixer is the mixer to map to. 
+ the left hand sliders (sliders 1 to splitIndex) are mapped to volumes;
+ the right hand sliders map to the mixer.editor parameters. 
+ lastIsMaster: if true, the rightmost control maps to server volume.
+ lastEdIsVol: if true, the last free slider on the right side is used for 
+ the edited proxy's volume.
+(
+m = NdefMixer();
+f.mapToPxMix(m, 1); 
+m.openEditZone;
+m.editor.proxy_(Ndef(\a));
+)
+ 
+ 
+( // test many proxies 
+Spec.add(\freqScale, [0.1, 10, \exp]);
+Spec.add(\rateScale, [0.1, 10, \exp]);
+10.do { |i| 
+ Ndef(("test" ++ i).asSymbol, { |rateScale = 1, freqScale = 1|
+ Pan2.ar(Ringz.ar(Impulse.ar(exprand(0.5, 4) * rateScale), exprand(300, 3000) * freqScale, 0.02), 1.0.rand2, 0.2) 
+ }).play(vol: 0.2)
+ ; 
+};
+)
+ 
+</body>
+</html>

Modified: JITMIDIKtl/PFKtl.sc
===================================================================
--- JITMIDIKtl/PFKtl.sc 2010-02-07 20:50:55 UTC (rev 1371)
+++ JITMIDIKtl/PFKtl.sc 2010-02-09 11:05:19 UTC (rev 1372)
@@ -4,7 +4,6 @@

init {
super.init;
- ctlNames = defaults[this.class];
lastVals = ();
}

@@ -32,16 +31,7 @@
)
);
}
-
- mapCC { |ctl= \sl1, action|
- var ccDictKey = ctlNames[ctl]; // '0_42'
- if (ccDictKey.isNil) {
- warn("key % : no chan_ccnum found!\n".format(ctl));
- } {
- ccDict.put(ccDictKey, action);
- }
- }
- // map to
+ // map to
mapToPxEdit { |editor, indices, lastIsVol = true|
var slKeys, lastSlKey;
indices = indices ? (1..8);
@@ -110,3 +100,158 @@
this.mapToPxEdit(mixer.editor, (splitIndex + 1 .. slKeys.size));
}
}
+
+PDKtl : MIDIKtl {
+ classvar <>verbose = false;
+
+ var <>step = 0.01;
+
+ *makeDefaults {
+
+ // implement nudge!
+ /* all midi chan 0,
+ scene 1: 0 - 15
+ scene2: 16 - 31
+ scene 3: 32 - 47
+ scene4: 48 - 63
+ */
+
+ // just one bank of sliders
+ defaults.put(this, (
+ 1: ( kn01: '0_0',
+ kn02: '0_1',
+ kn03: '0_2',
+ kn04: '0_3',
+ kn05: '0_4',
+ kn06: '0_5',
+ kn07: '0_6',
+ kn08: '0_7',
+ kn09: '0_8',
+ kn10: '0_9',
+ kn11: '0_10',
+ kn12: '0_11',
+ kn13: '0_12',
+ kn14: '0_13',
+ kn15: '0_14',
+ kn16: '0_15'
+ ),
+
+ 2: ( kn01: '0_16',
+ kn02: '0_17',
+ kn03: '0_18',
+ kn04: '0_19',
+ kn05: '0_20',
+ kn06: '0_21',
+ kn07: '0_22',
+ kn08: '0_23',
+ kn09: '0_24',
+ kn10: '0_25',
+ kn11: '0_26',
+ kn12: '0_27',
+ kn13: '0_28',
+ kn14: '0_29',
+ kn15: '0_30',
+ kn16: '0_31'
+ ),
+
+ 3: ( kn01: '0_32',
+ kn02: '0_33',
+ kn03: '0_34',
+ kn04: '0_35',
+ kn05: '0_36',
+ kn06: '0_37',
+ kn07: '0_38',
+ kn08: '0_39',
+ kn09: '0_40',
+ kn10: '0_41',
+ kn11: '0_42',
+ kn12: '0_43',
+ kn13: '0_44',
+ kn14: '0_45',
+ kn15: '0_46',
+ kn16: '0_47'
+ ),
+
+ 4: ( kn01: '0_48',
+ kn02: '0_49',
+ kn03: '0_50',
+ kn04: '0_51',
+ kn05: '0_52',
+ kn06: '0_53',
+ kn07: '0_54',
+ kn08: '0_55',
+ kn09: '0_56',
+ kn10: '0_57',
+ kn11: '0_58',
+ kn12: '0_59',
+ kn13: '0_60',
+ kn14: '0_61',
+ kn15: '0_62',
+ kn16: '0_63'
+ )
+ ));
+ }
+
+ // map to
+ mapToPxEdit { |editor, scene = 1, indices, lastIsVol = true|
+ var knobKeys, lastKnobKey;
+ indices = indices ? (1..8);
+
+ knobKeys = indices.collect { |i| ("kn" ++ (100 + i).asString.drop(1)).asSymbol}.postcs;
+
+ if (lastIsVol) {
+ lastKnobKey = knobKeys.pop;
+
+ // use last knob for proxy volume
+ this.mapCCS(scene, lastKnobKey, { |ch, cc, val|
+ var proxy = editor.proxy;
+ if (proxy.notNil) { proxy.nudgeVol(val - 64 * step) };
+ });
+ };
+
+ knobKeys.do { |key, i|
+ this.mapCCS(scene, key,
+ { |ch, cc, val|
+ var proxy = editor.proxy;
+ var parKey = editor.editKeys[i];
+ if (parKey.notNil and: proxy.notNil) {
+ proxy.nudge(parKey, val - 64 * step)
+ };
+ }
+ )
+ };
+ }
+
+ mapToPxMix { |mixer, scene = 1, splitIndex = 8, lastEdIsVol = true, lastIsMaster = true|
+
+ var server = mixer.proxyspace.server;
+ var knobKeys = (1..16).collect { |i| ("kn" ++ (100 + i).asString.drop(1)).asSymbol };
+ var lastKey;
+
+ // add master volume on knob 16
+ if (lastIsMaster) {
+ lastKey = knobKeys.pop;
+ Spec.add(\mastaVol, [server.volume.min, server.volume.max, \db]);
+ this.mapCCS(scene, lastKey, { |chan, cc, val|
+ var oldNormVal = \mastaVol.asSpec.unmap(server.volume.volume).postln;
+ var nudgedVol = (oldNormVal + (64 - val * step)).clip(0, 1);
+ server.volume.volume_(nudgedVol.ampdb)
+ });
+ };
+
+ // map first n knobs to volumes
+ knobKeys.keep(splitIndex).do { |key, i|
+
+ this.mapCCS(scene, key,
+ { |ch, cc, val|
+ var proxy = mixer.pxMons[i].proxy;
+ if (proxy.notNil) {
+ proxy.nudgeVol(64 - val * step);
+ };
+ };
+ )
+ };
+
+ this.mapToPxEdit(mixer.editor, scene, (splitIndex + 1 .. knobKeys.size));
+ }
+}

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

SF.net SVN: supercollider:[9819] trunk/build/SCClassLibrary/JITLib/extras/ extSoftSet.sc

2010-02-09T03:01:38Z

Revision: 9819
http://supercollider.svn.sourceforge.net/supercollider/?rev=9819&view=rev
Author: decampo
Date: 2010-02-09 11:01:38 +0000 (Tue, 09 Feb 2010)

Log Message:
-----------
added nudging for endless knob controllers.

Modified Paths:
--------------
trunk/build/SCClassLibrary/JITLib/extras/extSoftSet.sc

Modified: trunk/build/SCClassLibrary/JITLib/extras/extSoftSet.sc
===================================================================
--- trunk/build/SCClassLibrary/JITLib/extras/extSoftSet.sc 2010-02-08 18:44:01 UTC (rev 9818)
+++ trunk/build/SCClassLibrary/JITLib/extras/extSoftSet.sc 2010-02-09 11:01:38 UTC (rev 9819)
@@ -1,6 +1,21 @@
// Maybe rewrite as SoftSet(what, key, val, within, mapped, oldVal);

+ NodeProxy {
+
+ nudgeSet { |param, incr = 0.02|
+ var spec = param.asSpec;
+ var oldval = this.nodeMap.get(param).value ?? { this.getDefaultVal(param) ? 0 };
+ var oldnorm = spec.unmap(oldval);
+ var newnorm = (oldnorm + incr).clip(0, 1);
+ this.set(param, spec.map(newnorm));
+ }
+
+ nudgeVol { |incr = 0.02|
+ var spec = \amp.asSpec;
+ var oldval = spec.unmap(this.vol);
+ var newVol = spec.map((oldval + incr).clip(0, 1));
+ this.vol_(newVol)
+ }

softSet { |param, val, within = 0.025, mapped=false, lastVal|
var spec, newNormVal, oldVal, oldNormVal, maxDiff;

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Re: SynthDef method cleanup

2010-02-09T02:55:16Z

hi,

one opinion:

I think by default SynthDefs should just work as Synths and in patterns;
so they should by default go to the server and the SynthDescLib.
the clearest name I'v heard so far is:

SynthDef(\bla, { ... }).add; // = current memStore

If one does not want synthdefs in the lib (e.g. for efficiency optimisation),
one could do :

SynthDef(\bla, { ... }).send; // send to all running servers by default, unless server is given.

To remove a synthdef, the clearest so far:

SynthDef.remove(\bla); // clear it from SynthDescLib and from all running servers
( for symmetry, one could also provide : SynthDef.add(\bla, { ... }); )

Users should not have to worry about keeping in sync what the server knows and
what synthdesclib knows. this would reduce beginners confusion a lot IMO.

when is it _really_ necessary to store to disk?

I sometimes find it puzzling that synthdefs that still lie around on disk
get loaded on the server, so the server knows them, and they seem to work,
but then, not having made them from code in the lang, patterns dont work.

not storing to disk by default (unless explicitly forced) would remove that puzzle:
when they are not there, they are not there.

that would require touching up a lot of Synthdef code, but that code would get really simpler.

just 2c,
best, adc

On Feb 9, 2010, at 11:26 AM, Julian Rohrhuber wrote:

> Thank you for your comments. Much worse than flags are method and argument names that center on implementation instead of behavior. "memStore" is a border case in a sense. What I find is that we desperately need is a more abstract method whose name does not reflect how a SynthDef is made accessible as to make it work, but clearly says that it does so. As it is the most common thing, it should be clear and short. While memStore sticks once one has learned it, it is not a nice thing to have in the code - its name has nothing to do with why we use it really.
>
> One possibility would be to make store like "memStore" by default, and add diskStore. Flags in the class variables may be useful, but of course are ugly if you need a functionality only once. But well, let's hear some more opinions.. :)
>
>
> On 09.02.2010, at 07:51, Pelle Nilsson wrote:
>
>> Hi,
>>
>> Being only a new user still learning SC lurking on dev, I still can't
>> resist commenting on this issue from a new user point of view:
>>
>> Julian Rohrhuber <[hidden email]> writes:
>>
>>> Some methods of SynthDef are a bit hard to read. I've tried to clear
>>> thing up a bit and added a flag to send which stores the synthDesc
>>> (see patch).
>>>
>>> I'm not sure what the general opinion about this is. My experience is
>>> that the combinatorics of methods are hard to explain and that
>>> memStore is a too complicated name for a simple behaviour. To
>>> understand the name, one has to understand the history of
>>> supercollider. I would not be against using the method "add" instead,
>>> but as we are in a mess already, I tend to just make things work.
>>
>> It would be great to not use boolean flags here (or elsewhere). As a new
>> user, or probably an old user reading old code later, it is impossible
>> to read (or write) store(true), store(false), and store() and remember
>> what they mean (and which one the last is equivalent to). I always use
>> memStore and part of the reason is that I can remember what it does for
>> sure. I would love if the other version was called diskStore or
>> something similar.
>>
>> Knowing from other programming languages, trying to hide combinatorics
>> of methods by putting several methods in the same one and using flags to
>> select which of the hidden methods you really want to call was never a
>> solution to the problem.
>>
>> As others already said, the store methods are confusing enough to new
>> users already. It is great to hear that something is done about it, but
>> I hope you dev guys end up agreeing on some other solution. :)
>>
>> IMHO and all that.
>>
>> --
>> /Pelle
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
>> 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 (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/