Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editor integration #74

Closed
yaxu opened this issue Feb 10, 2018 · 17 comments
Closed

Editor integration #74

yaxu opened this issue Feb 10, 2018 · 17 comments

Comments

@yaxu
Copy link
Collaborator

yaxu commented Feb 10, 2018

Two ideas really, but thought I'd put them together as maybe general discussion about editor integration would be nice
First is, shall we create ten or eleven orbits by default, and have each connection (d1..) go to a different orbit (again by default)?
Second, would it be possible for an editor to subscribe to an rms analysis of each orbit? For display in the editor next to active patterns

@telephon
Copy link
Contributor

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
Copy link
Collaborator Author

yaxu commented Feb 10, 2018

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
Copy link

fdragovic commented Feb 10, 2018 via email

@telephon
Copy link
Contributor

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

@telephon
Copy link
Contributor

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

@fdragovic
Copy link

fdragovic commented Feb 10, 2018 via email

@echophon
Copy link

echophon commented Feb 10, 2018 via email

@telephon
Copy link
Contributor

@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
Copy link
Contributor

bgold-cosmos commented Feb 10, 2018

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
Copy link
Collaborator Author

yaxu commented Feb 10, 2018

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
Copy link

fdragovic commented Feb 10, 2018 via email

@yaxu
Copy link
Collaborator Author

yaxu commented Feb 11, 2018

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

@telephon
Copy link
Contributor

telephon commented Feb 11, 2018

@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
Copy link

fdragovic commented Feb 12, 2018

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
Copy link
Collaborator Author

yaxu commented Feb 13, 2018

Thanks @fdragovic, I'll try this out!

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

@telephon
Copy link
Contributor

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
}
)

This was referenced Feb 14, 2018
@yaxu yaxu mentioned this issue Feb 19, 2018
@yaxu
Copy link
Collaborator Author

yaxu commented Feb 21, 2018

Thanks very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants