#333

This looks promising, cheers!

#334

https://www.instagram.com/p/B3r2pWCJrZC/?igshid=13vg57axfpplm

just getting my feet wet…
not yet breathing underwater
at the bottom of the ocean

(http://archive.monome.org/community/discussion/comment/213275#Comment_213275
helpful getting the non-varibright gs64 working with grid studies, cheers)
https://soundcloud.com/k-blamo/sleepyhitsonedisquiet0350

1 Like
#335

It would be great to incorporate this into the index!

1 Like
#336

I’m way way behind on this thread, and a novice at SC, but was wondering if this was something that could be run on Norns to process the incoming sound?

#337

crucialfelix’s supercollider.js library might be a place to start for webserver support as well.

#338

I was hoping to use this to export MIDI output from SC as a notated score: https://github.com/smoge/superfomus but it doesn’t work due to operating system incompatibility. any possible workarounds besides downgrading to 10.5? moreover, is anyone familiar with quarks/extensions similar to FOMUS that can render a file (e.g. XML) suitable for importing to a notation application e.g. Sibelius? I would go ahead with SimpleMIDIFile or something but we all know how useless MIDI-to-notation conversion can be.

#339

Hi,

hope that’s the right place for Supercollider/Grid newbie question. I am trying to work my way through the SC Grid Studies.

Running on Linux (Mint 18.1) I start serialosc and get a

serialosc [m1000867]: connected, server running on port 14582

When I am trying to run grid-studies-2.scd:

(
Server.default = Server.local;

~m = MonoM.new("/monome", 0);

s.waitForBoot({

~m.useDevice(0);

OSCFunc.newMatching(
		{ arg message, time, addr, recvPort;
			~m.ledset(message[1], message[2], message[3]);

		}, "/monome/grid/key");

});

)

I get the following error:

changed default server to: localhost
-> localhost
Using device on port#nil
ERROR: Primitive '_NetAddr_SendMsg' failed.
Complete error message: 
changed default server to: localhost
-> localhost
Using device on port#nil
ERROR: Primitive '_NetAddr_SendMsg' failed.
Wrong type.
RECEIVER:
Instance of NetAddr {    (0x429e208, gc=00, fmt=00, flg=00, set=02)
  instance variables [4]
    addr : Integer 2130706433
    port : nil
    hostname : "localhost"
    socket : nil
}
PATH: /home/marty/projects/sonicpi/supercollider/grid-studies-sc/grid-studies-2.scd

PROTECTED CALL STACK:
	Meta_MethodError:new	0x1448840
		arg this = PrimitiveFailedError
		arg what = Wrong type.
		arg receiver = a NetAddr(127.0.0.1, nil)
	Meta_PrimitiveFailedError:new	0x144ee00
		arg this = PrimitiveFailedError
		arg receiver = a NetAddr(127.0.0.1, nil)
	Object:primitiveFailed	0xfa2280
		arg this = a NetAddr(127.0.0.1, nil)
	MonoM:useDevice	0x1fdde00
		arg this = Ports:List[  ]
		arg devicenum = 0
	a FunctionDef	0x3297ed8
		sourceCode = "{

~m.useDevice(0);

OSCFunc.newMatching(
		{ arg message, time, addr, recvPort;
			~m.ledset(message[1], message[2], message[3]);

		}, \"/monome/grid/key\");

}"
	Routine:prStart	0x1c8b080
		arg this = a Routine
		arg inval = 1661.576148267

CALL STACK:
	MethodError:reportError
		arg this = <instance of PrimitiveFailedError>
	< closed FunctionDef >
		arg error = <instance of PrimitiveFailedError>
	Integer:forBy
		arg this = 0
		arg endval = 0
		arg stepval = 2
		arg function = <instance of Function>
		var i = 0
		var j = 0
	SequenceableCollection:pairsDo
		arg this = [*2]
		arg function = <instance of Function>
	Scheduler:seconds_
		arg this = <instance of Scheduler>
		arg newSeconds = 1661.62067583
	Meta_AppClock:tick
		arg this = <instance of Meta_AppClock>
		var saveClock = <instance of Meta_SystemClock>
	Process:tick
		arg this = <instance of Main>
^^ The preceding error dump is for ERROR: Primitive '_NetAddr_SendMsg' failed.
Wrong type.
RECEIVER: a NetAddr(127.0.0.1, nil)

As a side note: I can however successfully use Animalation, also based on SuperCollider. Both use monom to connect to the grid but obiously the grid studies in my case don’t get the necessary (port) information, which I can supply in the Animalation patch via the setup variable gridDevicePort.

Can someone possibly point me into the right direction?

#340

for whatever reason, MonoM has an empty device list when you run the script.

you can try ~m.deviceList to repopulate it before calling ~m.useDevice(0) .

useDevice uses its argument as an index into the list of discovered device ports. so normally you don’t have to set the port manually. but you could also try ~m.usePort(14582).

1 Like
#341

@zebra

Thanks! That did the trick.

#342

Has anybody tried the Yamaha TX81z UGen?

I’m getting lots of clicks every midi noteOff when setting the gate to 0 (if midi is released before end of envelope), using the example code. if i don’t close it each note with gate, it works perfectly but my cpu explodes. Anyone having experience with this?

1 Like
#343

Wondering if anyone can help me with some problems passing args into Synths. Here’s a bit of demo code that shows the problem I’m hitting:

(
SynthDef("aSynth", {
	arg myArg;
	((myArg + 10) - 40000000).poll(2, "Difference"); // Expecting 10, seeing 8
}).add;
)
Synth("aSynth", [\myArg, 40000000]);

It only occurs with large numbers… but not that large right? In the real code I’m trying to pass in a frame number for a sample.

#344

waaat… that’s super frigging bizarre.

i can get other errors too, unless i’m being a dunce. something special about 2**25?

s = Server.default;
s.waitForBoot { Routine {

	SynthDef("test", {
		arg a=40000000, b=10.0, c=40000000;
		((a + b) - c).poll(2, "Difference"); // Expecting 10, seeing 8
	}).send(s);
	s.sync;

	postln('new default synth, difference should be "10"');
	x = Synth("test");

	2.wait;

	postln('restarting... ');
	x.free;
	s.sync;
	b = 10;
	a = 2 ** 25 - 1 - b;
	postln('new non-default synth, difference should be "10" (offset: ' ++ a ++ ')');
	x = Synth("test", [\a, a, \b, b, \c, a]);

	2.wait;

	postln('restarting... ');
	x.free;
	s.sync;
	b = 10;
	a = 2 ** 26 - 1 - b;
	postln('new non-default synth, difference should be "10" (offset: ' ++ a ++ ')');
	x = Synth("test", [\a, a, \b, b, \c, a]);

	2.wait;


// why does this work???
	postln('changing values... difference should be "200"');
	x.set(\a, 40000000);
	x.set(\c, 40000000);
	x.set(\b, 200);
}.play; }

dunno if this is the OSC layer or synth instantiation or what, but seems like a bug

#345

Thanks for taking a look, you’re making me feel less crazy at least! I’ll open up an issue on the SC github and report back…

#346

Got a quick reply: it is just a floating point precision issue. Will have to do some more thinking about how to get around it in my project though.

#348

ok, that makes sense. guess i forgot that IEEE-754 defines a 24-bit mantissa for 32b binary (in my head it was 26 or something - see? dunce).

BufRd does document that it only addresses 2^24 samples, which should have been a clue.

#349

I wonder if anyone can help with a SC performance question?

I’ve built a simple sampler application. A stripped down version that shows the issue looks like this:

s.waitForBoot({
~b1 = Buffer.read(s, "1.wav");

SynthDef(\sampler, {
        arg obs=0, buf, rate=1, amp=1;
        var sig;
        sig = PlayBuf.ar(1, buf, rate, \t_tr.kr(1, 0), doneAction: Done.freeSelf);
        Out.ar(obs, sig);
}).add;

~handler = {
        arg msg, time, addr, recvPort;
        Synth(\sampler, [\buf, ~b1.bufnum]);
};

n = NetAddr.new("127.0.0.1");
o = OSCFunc(~handler, '/sampler/1', n, 49162);
});

I’m running this sclang script from the command line (on OS X 10.14 on a macbook pro) with sclang sampler.scd.

To reproduce the issue I’m seeing, in a separate terminal window I’m triggering the sample via OSC using sendosc in a steady pulse with while true; do sendosc 127.0.0.1 49162 /sampler/1; sleep 0.5; done.

If I do anything fairly intensive on my machine while this is running (for example open a new browser tab in FF), the audio stutters. It sounds like some of the OSC events are not arriving in time, and sometimes get backed up before all firing at once.

Is this just something to be expected when running SC under OS X with other things happening on the machine, or is there something wrong in the way I’m using SC? Are there any tips for achieving more solid timing?

#350

That’s really weird, you should be able to trigger 100s of this kind of synths per second on any current machine.
Do you experience the same thing when running your scd from the SC IDE ?
Maybe ask for some help on scsynth.org forum.

#351

Do you experience the same thing when running your scd from the SC IDE ?

Yes, it seems so. I notice that the CPU indication in the IDE is well below 1%. It doesn’t sound like the kind of crackle/glitch you get when the machine is under load, it’s almost as if the OSC messages are getting delayed and arriving late?

#352

IMO this indicates that the issues may lie in the process running sclang. If you send the equivalent command directly to scsynth the issues may go away. So you might want to try that out.

I’ve never had issues like this with messages triggered every 0.5 seconds, though I mostly do the scheduling in sclang itself.

On the norns (raspberry pi) I’ve noticed OSC messages getting dropped between the different layers, but only when a lot of messages are sent in a short amount of time (practically at the same time). We haven’t narrowed down why that happens.

#353

Thanks @jah that’s really helpful!

I took a look at the server command reference and was able to send the equivalent OSC commands directly to the server with:

while true; do sendosc 127.0.0.1 57110 /s_new s sampler i -1; sleep 0.5; done

(where 57110 is the port assigned to the supercollider server when it starts). Unfortunately the problem persists. I am planning to run this code on a raspberry pi eventually (I’m writing a sequencer in Rust with a SC backend) but it’d be nice to understand what’s happening on my (presumably much more capable) laptop :slight_smile: