Editor integration about superdirt

[telephon]

yes, why not.

for the first: we just change the startup file, and add default orbit args in tidal? One thing to worry about (or rather: to test) is if this might lead to a very large cpu load when you use many at the same time, all with effects. also, it is an aesthetic choice. it sounds very differently.

rms: yes. can we open a port in tidal that dirt can send to?

[yaxu]

Yes default orbit args would be added to the editor startup config. I'll experiment with this and see what the cpu load is like.

(Currently I'd say global effects don't work well when multiple patterns send to the same orbit. I haven't investigated in detail but think when a pattern doesn't set a parameter, it turns off the effect.)

rms - I think it wouldn't be tidal itself that would open the port, but the editor. I'm working on a new text editor in ncurses, so the vu meter would be rendered with extended ascii / unicode blocks, so wouldn't need to be high resolution in this case! FFT might also be nice to experiment with. I'd want to mirror the functionality in classic dirt.

[fdragovic]

either they get turned off, although it sounds like it's just the default values that are accessed because delays and reverbs jump back and forth between values... would be really cool if there was a way around that! also, ncurses editor sounds teh sick :D

[telephon]

yes in the end it just depends on what kind of orbit-effects you use.

[telephon]

if we would be picky, we would say that a delay is local, but a room is global. we would need nested orbits...

[fdragovic]

sounds like that would be another cpu issue though seeing as those global effects are always on standby? maybe there is a way to ignore the defaults if there is something already sending values on that orbit?

…

On Sat, Feb 10, 2018 at 6:01 PM, Julian Rohrhuber ***@***.***> wrote: if we would be picky, we would say that a delay is local, but a room is global. we would need nested orbits... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#74 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOffrkryEEEiV6tdHbPW6arqxpbGBAq_ks5tTcthgaJpZM4SA5r1> .

[echophon]

Would it make sense to have an orbit or two dedicated for global fx? With individual dirt channels using a send 0-1.0 value to feed the signal into the effect. On Sat, Feb 10, 2018 at 9:04 AM Filip Dragovic <[email protected]> wrote:

…

sounds like that would be another cpu issue though seeing as those global effects are always on standby? maybe there is a way to ignore the defaults if there is something already sending values on that orbit? On Sat, Feb 10, 2018 at 6:01 PM, Julian Rohrhuber < ***@***.***> wrote: > if we would be picky, we would say that a delay is local, but a room is > global. we would need nested orbits... > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > < #74 (comment) >, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AOffrkryEEEiV6tdHbPW6arqxpbGBAq_ks5tTcthgaJpZM4SA5r1 > > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#74 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFuCmK3P6QIMLRxT1Mcx4yA4R2P-g0A0ks5tTcwrgaJpZM4SA5r1> .

[telephon]

@fdragovic if you don't use them, they don't eat. But if you do, each parallel dirt pattern will use one each instead of one total.

[bgold-cosmos]

I am working on a change to the global effects so that messages don't stomp on each other quite so much. It makes it much easier to have multiple things going on in a single orbit.
https://github.com/bgold-cosmos/SuperDirt/tree/global-send
Still in progess, and the solution I came up with is kind of ugly, but it seems to be working so far. I'll have another update to that branch in a few days implementing it for all the global effects.

[yaxu]

In terms of an interface, I guess something like this to start sending rms values:
~dirt.send_rms(addr="127.0.0.1", port=6020, hz=4)
hz being number of times to send the rms values per second.

The OSC message could have path /rms followed by one value per orbit.

@bgold-cosmos nice one!

[fdragovic]

this seems like it could be useful http://doc.sccode.org/Classes/SendPeakRMS.html i wanted to play around with adding some different types of distortion as well tomorrow so ill give it a go while im at it (:

[yaxu]

I implemented sending /rms out from classic dirt
tidalcycles/Dirt@227b508

[telephon]

@bgold-cosmos If we really want separate busses per orbit, then we shouldn't add them separately, variable by variable. This makes the system hard to extend.

Your prototype will definitely help in finding the best solution - thanks!

[fdragovic]

hey @yaxu this should send the Peak & RMS values at the given refresh rate on the sclang port

{
var busses = ~dirt.orbits.collect { |x| x.dryBus };
(1..~dirt.orbits.size).do { |i|
  SendPeakRMS.kr(InFeedback.ar(Select.kr((i-1) /*n*/, busses), ~dirt.numChannels),
                 4, //refresh rate
                 3, //peak lag 
                 "/meter" ++ (i-1));
}}.play

3rd parameter is peak and 4th RMS, and it's sending to 57110 because it's assuming it's for sclang, but you can also forward them with and OSCFunc (this one just posts them (: )

OSCFunc({ |msg|
  "peak: %, rms: %".format(msg[3], msg[4]).postln
}, '/meter0');

[yaxu]

Thanks @fdragovic, I'll try this out!

For now I have this working with classic dirt: https://www.youtube.com/watch?v=dIXRRfxNH2s

[telephon]

there is a typo in the code, this should do it (untested!):

(
~dirt.orbits.do { |orbit, i|
	{
		SendPeakRMS.kr(
			InFeedback.ar(orbit.dryBus, ~dirt.numChannels),
			4, //refresh rate
			3, //peak lag 
			"/meter" ++ (i-1)
		);
	}.play
}
)

[yaxu]

Thanks very much!