#41

makes it very enticing all over again

#42

does this work for anyone? Iā€™m seeing slang at 100%, but this is not causing the cpu to drop :frowning:

#43

Iā€™ve never experienced this 100% cpu bug in spite of running sclang without QT. No idea why I lucked out there.

#44

ok, the guys behind Bela seem to have found a fix :slight_smile:

just applied to my local build at all works, without stopping aliveThread.

Im finding quite a few problems with SC headless, not only this, but also the issue with it throw exceptions when started without stdin (which took me a while to find a workaround for)
(Im using dev, so 3.9beta 1)

#45

yeah thatā€™s the same fix suggested here:
http://supercollider.github.io/development/building-raspberrypi

and suggested by the bela folks on the original GH issue thread (already linked above)

there have been mixed reports of the efficacy of this patch.

itā€™s very strange, simply stopping the keepalive thread works for me.
also, running a separate scsynth process and connecting to it as a remote bypasses the keepalive thread in the first place ( i think - anyway i donā€™t see the cpu spike.)

but if you are seeing the usage without the keepalive threadā€¦ thatā€™s bizarre. a true heisenbug.

1 Like
#46

dumb question :slight_smile:
(as Iā€™m pretty sure its showing a fundamental misunderstanding)

Server.default=Server.remote("aserver",NetAddr("organelle",57110));
s=Server.default;
a = OSCFunc(
    { arg msg, time, addr, recvPort; [msg, time, addr, recvPort].postln; }, 
     '/knobs',
     nil, 
     4000);

so the above is suppose to , connect to the remote scsynth. then register an osc hander listening on port 4000ā€¦ but I donā€™t get any messages
yet the same OSCFunc run on SCLang locally on the box works

so im a little confused, I thought that the OSCFunc was passed to the server to execute, so should execute the same, locally or remoteā€¦
or is OSC handling part of client side? is it possible for it to be run on the server?

#47

yes

is it possible for it to be run on the server?

no, i donā€™t think so. server understands hardcoded set of commands:
http://doc.sccode.org/Reference/Server-Command-Reference.html

to me, this suggests that in startup on organelle, youā€™d launch something that listens to some set of commands you define to do ā€œstuffā€ from a host computer. in addition, presumably, to listening for OSC from the Organelle_controller woop, i mean Organelle_UI process.

1 Like
#48

ok, so no comms on the server , osc and midi done on clientā€¦
so I assume I could have a local client (sclang) processing midi and custom osc, and some how sending out notifications, which other (remote) clients of the server could pick up and process.

Iā€™m thinking a bit like the addDependent / change events mentioned earlier in this threadā€¦ or are these local to an sclang?

for the ā€˜performanceā€™ side its all going to be be local, but I want to be able to develop the SC synth defs on a mac using the SC IDEā€¦ then copy them across when workingā€¦
(Iā€™ve got an OscProxy, but its easier if I can keep it all in SC)

2 Likes
#49

makes sense.

in the SC world, itā€™s a pretty common paradigm to have one sclang/scsynth on a network connected to a sound system, and other clients that initiate stuff happening (think about a classroom / workshop / networked jam session.)

you can just remote-execute SC code directly:

n = NetAddr("127.0.0.1", NetAddr.langPort);

OSCdef(\execRemote, {
	|msg, time, addr, recvPort|
	this.interpret(msg[1]); //  try to compile and execute the payload string 
},'/execRemote', n);

and/or you can have remote clients talk to the organelleā€™s scsynth directly (send synthdefs, control synths/busses, &c)

(or anything in between, including some kind of proxy class.)

iā€™d be interested to see any systems you develop for structuring this kind of thing!

yes. they are methods of Object. an instance of sclang (client) has its own interpreter state. multiple clients can communicate through OSC+UDP/TCP and thats about it.

client/server of course use OSC also; in one direction via the server commands (either raw, or wrapped in sclang class methods); in the other direction via ugens like SendTrig, SendReply, SendRMS.

since recent versions, client/server on the same machine can do some of their IPC over shared memory instead of UDP/TCP. this enabled the synchronous methods for polling and setting control busses. these are a lot more efficient if you are gonna do a lot of client-side operations on control busses, so might factor into any kind of multi-client design.

and woop, it occurred to me that JITLib has some features intended to facilitate collaborative networked live-coding, which you may be interested in (itā€™s not a library iā€™ve used much myself, beyond a bit of Pdef)

2 Likes
#50

Iā€™m very interested in your findings on this.

For quite some time I have planned to refactor a SC drum machine app Iā€™m working on similarly: one part realtime audio process (scsynth), one part core logic/sequencing (data structures for sequencing, scheduling), one part UI, all three decoupled and communicating via well-defined OSC interfaces. This would make for a modular design where any part could be swapped out for a different implementation.

Erlang father Joe armstrong: ā€œsend messages to things and ask them to do thingsā€ rather than ā€œperforming open brain surgeryā€ on things:
http://joearms.github.io/published/2016-01-28-A-Badass-Way-To-Connect-Programs-Together.html

The latter two parts of my app are currently in the same ā€œaddress spaceā€. The Grrr based UI ā€œlistens toā€ to core/sequencing events via addDependant / update for incremental UI update and utilizes synchronous ā€œgetProperty()ā€ calls for UI refresh that not triggered by events (ie, on startup). Decoupling the parts would, I think, boil down to changing addDependant / update events to OSC messages and find a way to work around and phase out the synchronous ā€œgetProperty()ā€ calls. This would be a fun excercise but Iā€™m not sure how it would end up in practice with regard to performance. The events communicated are fairly large and many. Feels like it all kind of moves towards Functional Reactive Programming.

@TheTechnobear @zebra youā€™re discussions on networked control of SuperCollider got me thinking about this library (which I havenā€™t tried myself):

2 Likes
#51

another newbie Q. :slight_smile:

how from within sclang can I get it to interpret an sc script file?
(or even the equivalent of an ā€˜includeā€™ file statement would do)

the best Ive come up with so far is:

(
g = File("~/Documents/SuperCollider/test.sc".standardizePath,"r");
g.readAllString.interpret;
g.close;
)

but Id prefer to interpret the stream, so as not to load the entire file into memory (as it could be large)

other things Ive tried:
treat as a stream

(
g = File("~/Documents/SuperCollider/test.sc".standardizePath,"r");
g.do(
	{ 
		arg v; 
		v.asString.interpret;
	}
);
g.close;
)

It does not like this, as interpret is actually needing a full SC commandā€¦ rather than just adding to a buffer till its ā€˜completeā€™ā€¦ so this indicates to me, any kind of parsing into interpret will fail, since things like brackets and scoping come into playā€¦

thoughts?

background:
ok, so what Im trying to do , is make it so the user only has to provide one fileā€¦ and it to be run.

to do this, I have another file ā€˜mother.scdā€™ which sets up various system things, boots the server, and then I want to do something like

  s.waitForBoot { (
        s.initTree;
        include("main.scd");
    )};

where main.scd is the users ā€˜patchā€™ file.

now i dont want to put everything in startup.scd, for a couple of (perhaps dubious) reasons
most importantly, I want the ā€˜mother.scdā€™ file to be overridable, to allow different behaviour , and startup.scd is ā€˜globalā€™ afaik

I guess the main issue Iā€™m facing isā€¦ that I dont want users to have put the waitForBoot in their script, as this is pretty ugly.
I suppose one other option, is for me to start scsynth directly, and then wait a second or two, before starting sclang, but that seems a bit hacky.

p.s.though Im an experience C++ programmer, Iā€™m trying to keep it simple at the moment, as Im not that experience with SCā€¦ (so avoiding SC classes) and dont want to get side-tracked too much, as Id like to deliver at least the skeleton quicklyā€¦ then I can improve it with custom class/ugens later :slight_smile:

Bonus Question:
anyone know of a (lightweight, think rPI!) ) web based editor for SC? (linux)
If not Iā€™m thinking of a simple ACE based editor running on cherrypi, but this will only provide basic functionality, and I dont want to reinvent the wheel :wink:

#52

https://composerprogrammer.com/teaching/supercollider/sctutorial/Technicalities/07%20Dealing%20with%20Large%20Projects.html

1 Like
#53

thanks that didnā€™t work, loadPath, and excutePath, just report as ā€˜not understoodā€™ (on SC 3.8) , but did allow me to find :

"/tmp/patch/main.scd".load

this is a much nicer syntax, thank you :slight_smile:

1 Like
#54

yeah, AFAIK there is no way to get that deep into the parser from within sclang; you can only interpret complete and valid statements. pretty normal for an interpreted language (same as lua and so forth.)

but, look at the methods for Interpreter in Kernel.sc. as in many interpreted languages, code execution has two steps: 1) compile to bytecode, 2) execute the bytecode

in sclang the .interpret method is just convenience. the underlying method is .compile, which returns a Function (compiled bytecode) if the argument is a valid SC chunk, and nil if it isnā€™t.

f = "1+1".compile; // f is a Function
f.value; // prints "2"
f = "1 + ".compile; // f is 'nil' 
f.value; // error

so if you really want to make a REPL that handles incomplete statements, it should be doable, in the same manner that most REPLs do it:

  1. make a buffer
  2. when you get input, add it to the buffer and try to compile
  3. if the result is nil, do nothing and wait for more input
  4. if the result is a Function, evaluate the function and clear the buffer

i donā€™t think this would work with local variables though. in the same way that you canā€™t use local variables from a lua REPL prompt.

try .executeFile (or i guess .load as youā€™ve discovered, i guess thatā€™s a new alias?)

hereā€™s a snippet that shows up a lot in my performance scripts, for local ā€œincludes.ā€ (for a given performance i uusally have a directory with a master script, and some number of child scripts that do this or that. but really universal modules or boilerplate are done in classes, not scripts.)

p = PathName.new(Document.current.path).pathOnly;
x = { |f| this.executeFile(p ++ f); };

i donā€™tā€¦ and am working (a little bit) towards a similar goal actually. currently iā€™m just taking a sclang process and wrapping its stdin/stdout in a little nanomsg program. this makes it usable by local IPC sockets or websockets.

was thinking the next step would be a tiny webserver, but was thinking lighter than python - maybe monkey or mongoose.

thanks for pointing at https://ace.c9.io/, thatā€™s the piece i hadnā€™t started thinking about

2 Likes
#55

Thereā€™s also the annoying restriction that local variables can only be defined at the start of a block in SC.

#56

well yeah, local variables really are of limited use in SC. iā€™ve never been a big fan of the style that you see so much in the help docs:

( // create a local scope
var bla; 
// do stuff with bla
)

itā€™s a weird idiosyncracy to have to select this whole chunk in the editor and evaluate it, and of course bla is out of scope as soon as youā€™ve done so

i like global variables just fine in SC. because they donā€™t really exist! there is actually just one global variable, which is an Environment, which is just a specialized identity dictionary. so this works:

~abc = 123;
e = Environment.new;
e.push; // we've made a new "global namespace"
~abc.postln; // now this is nil
~bla = 456; // do some stuff

e.pop; // restore the old "global namespace"
~bla.postln; // nil
~abc.postln; // 123

to me, itā€™s best to just prototype with global (pseudo-)variables. if necessary, can swap Environments or use Events in a similar fashion. when something is ā€œset in stoneā€ it can be turned into a class.

this is again analogous to typical practice in Lua, where you would keep all your messy state stuff in a global table that can be easily marked for garbage collection or &c. when your prototyping is complete the table can be made local and put in a module.

5 Likes
#57

sorry to reply to myself, but this is absolutely not true and i donā€™t know why i thought it.

this works fine:

// Environment acting as psuedo-class for prototyping an incremental interpreter
e = Environment.make({
	~buf = "";
	~reset = { ~buf = ""; };
	~eval = { |str|
		~buf = ~buf ++ str;
		~fn = ~buf.compile;
		if(~fn.notNil,  {
			~fn.value;
			~reset.value;
		}, {
			postln("..."); // incomplete statement?
		});
	};
})

e.push; // use this environment as global namespace

~eval.value("postln(1+1);"); // prints "2"
~eval.value("( var blarg = 2; "); // prints "..."
~eval.value(" postln(blarg * 5); )"); // prints "10"

e.pop; // restore last environment

so, we successfully opened a scope and declared a local variable with one call to this toy interpreter, then used the local and closed the scope in a second call. of course we canā€™t access the local now but thatā€™s as expected.

(iā€™m tying to think of some edge case that would break this by successfully compiling before the scope is closedā€¦ feel like it exists)

3 Likes
#58

SC not freeing nodes?

Ok, so Ive got a weird one, perhaps lack of understandingā€¦
Im using done actions to free up synth nodes via a gate on an envelope

I can hear the synth gate is closed (due to sustain) , yet I can still occasionally see the node on the tree

~voices = Dictionary.new;
~notesfunc = {
	arg func, msg, note, vel;
	if(vel>0 , {
		if(~voices[note]!=nil,{~voices[note].set(\gate,0);});
		~voices[note] = Synth.new(\testSynth,[
			\freq, note.midicps,
			\cutoff, ~cutoff,
			\amp, (vel / 3.0) .clip(0,1.0)
		]
		);
	} , {
		if(~voices[note]!=nil,{~voices[note].set(\gate,0);});
		~voices[note] = nil;
	};)
};
SynthDef(\testSynth, {
		arg freq=440,gate=1,cutoff=440,amp=0.3;
		var sig,env;
		sig = Saw.ar(freq);
		env = EnvGen.ar(Env.adsr(),gate,doneAction:2);
		sig = sig * env * amp;
		sig = LPF.ar(sig,cutoff.clip(10,24000));
		Out.ar(~outL,sig!2);
	}
).add;

code is trivial reallyā€¦
as I say, I can hear the gate has closed, and there are no ā€˜hang notesā€™ā€¦
so why is the doneAction not freeing up the synth?
(I also can see the dictionary is ā€˜emptyā€™, so definitely gone thru the code to cleanup)

(Ive tried on both 3.9 on the Organelle, and 3.8 on the mac, and same behaviour)

Bonus question :slight_smile:
Is there a way I can grab hold of the Synth given the nodeID in sclang?
e.g. if I know the synth is 1087

I want to do something like
a=Synth.fromNodeID(1087);
a.isPlaying;

#59

Not sure of the answer, might be something subtle, but try with a simpler envelope like Env.perc for starters. Also your EnvGen should probably be .kr unless you like wasting CPU cycles for no reason :slight_smile:

Edit: nevermind, play doesnā€™t matter hereā€¦

#60

I tried out this code in my local SC and it seemed to work just fine:

(
SynthDef(\testSynth, {
		arg freq=440,gate=1,cutoff=440,amp=0.3,out;
		var sig,env;
		sig = Saw.ar(freq);
		env = EnvGen.ar(Env.adsr(),gate, doneAction:2);
		sig = sig * env * amp;
		sig = LPF.ar(sig,cutoff.clip(10,24000));
		Out.ar(out,sig!2);
	}
).add;
)

x = Synth.new(\testSynth, [\freq, 60.midicps, \cutoff, 2000])
x.set(\gate, 0)

So maybe you have something else going on?