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

class library: plot relative to target synth #3088

Merged
merged 10 commits into from May 12, 2018

Conversation

Projects
None yet
7 participants
@telephon
Member

telephon commented Aug 1, 2017

Sometimes, one needs to plot values from a synth that depends on node
order. E.g. a synth that reads from a bus. This patch allows us to
determine the point at which the plotting synth is inserted in the node
order. It is inserted after the target node. By default, this is the
default group of the default server. This follows the asTarget
interface, as documented in scdoc.

class library: plot relative to target synth
Sometimes, one needs to plot values from a synth that depends on node
order. E.g. a synth that reads from a bus. This patch allows us to
determine the point at which the plotting synth is inserted in the node
order. It is inserted _after_ the target node. By default, this is the
default group of the default server. This follows the `asTarget`
interface, as documented in scdoc.
@joshpar

This comment has been minimized.

Show comment
Hide comment
@joshpar

joshpar Aug 1, 2017

Member
Member

joshpar commented Aug 1, 2017

@telephon

This comment has been minimized.

Show comment
Hide comment
@telephon

telephon Aug 1, 2017

Member

Ah definitely. I don't have the time now, but it should be easy.

Also, I'd love to have a node-based server meter that lets you see all the signals of all the nodes and busses. But that's for later :)

Member

telephon commented Aug 1, 2017

Ah definitely. I don't have the time now, but it should be easy.

Also, I'd love to have a node-based server meter that lets you see all the signals of all the nodes and busses. But that's for later :)

@telephon

This comment has been minimized.

Show comment
Hide comment
@telephon

telephon Aug 1, 2017

Member

(for scope, it is in BusScopeSynth::play).

Member

telephon commented Aug 1, 2017

(for scope, it is in BusScopeSynth::play).

@adcxyz

This comment has been minimized.

Show comment
Hide comment
@adcxyz

adcxyz Aug 5, 2017

Contributor

really nice, thanks!

Also, I'd love to have a node-based server meter that lets you see all the signals of all the nodes and busses. But that's for later :)

Maybe ProxyMeter (in JITLibExtensions) could be extended/adapted easily for this ?

Contributor

adcxyz commented Aug 5, 2017

really nice, thanks!

Also, I'd love to have a node-based server meter that lets you see all the signals of all the nodes and busses. But that's for later :)

Maybe ProxyMeter (in JITLibExtensions) could be extended/adapted easily for this ?

@adcxyz adcxyz requested review from adcxyz and removed request for adcxyz Aug 5, 2017

class library: rename server to target in plot methods
This applies to the methods:

- Function:plot
- Function: loadToFloatArray
- Function:asBuffer

@snappizz snappizz changed the base branch from master to develop Sep 24, 2017

@telephon telephon requested a review from muellmusik Oct 2, 2017

@muellmusik

Generally I like the idea. A few comments.

Show outdated Hide outdated HelpSource/Classes/Function.schelp
Show outdated Hide outdated HelpSource/Classes/Function.schelp
@telephon

This comment has been minimized.

Show comment
Hide comment
@telephon

telephon Oct 4, 2017

Member

OK, here are some improvements - thanks for your ideas!

Member

telephon commented Oct 4, 2017

OK, here are some improvements - thanks for your ideas!

@telephon

This comment has been minimized.

Show comment
Hide comment
@telephon

telephon Nov 2, 2017

Member

ping

Member

telephon commented Nov 2, 2017

ping

@adcxyz

adcxyz requested changes Nov 2, 2017 edited

little glitch: in Function.schelp lines 455 and 457, minimum and maximum are swapped between argument names and description lines. everything else looks good!

@adcxyz

adcxyz approved these changes Nov 8, 2017

@brianlheim brianlheim added this to the 3.10 milestone Feb 4, 2018

@@ -769,14 +769,13 @@ Plotter {
+ Function {
plot { |duration = 0.01, server, bounds, minval, maxval, separately = false|
plot { |duration = 0.01, target, bounds, minval, maxval, separately = false|

This comment has been minimized.

@brianlheim

brianlheim Feb 4, 2018

Member

changing function parameter names is a breaking change...

@brianlheim

brianlheim Feb 4, 2018

Member

changing function parameter names is a breaking change...

@@ -311,15 +313,24 @@ Function : AbstractFunction {
^buffer
}
loadToFloatArray { |duration = 0.01, server, action|
this.asBuffer(duration, server, { |buffer|
loadToFloatArray { |duration = 0.01, target, action|

This comment has been minimized.

@brianlheim

brianlheim Feb 4, 2018

Member

same here, breaking change

@brianlheim

brianlheim Feb 4, 2018

Member

same here, breaking change

asBuffer { |duration = 0.01, server, action, fadeTime = (0)|
var buffer, def, synth, name, numChannels, rate;
server = server ? Server.default;
asBuffer { |duration = 0.01, target, action, fadeTime = (0)|

This comment has been minimized.

@brianlheim

brianlheim Feb 4, 2018

Member

also breaking change

@brianlheim

brianlheim Feb 4, 2018

Member

also breaking change

@brianlheim

This comment has been minimized.

Show comment
Hide comment
@brianlheim

brianlheim Feb 4, 2018

Member

I would like to see this go through, but I think the general policy we've been following is not to change parameter names of methods because it potentially breaks user code. I don't know what to do in this case, because it makes semantic sense to change it.

Member

brianlheim commented Feb 4, 2018

I would like to see this go through, but I think the general policy we've been following is not to change parameter names of methods because it potentially breaks user code. I don't know what to do in this case, because it makes semantic sense to change it.

@telephon

This comment has been minimized.

Show comment
Hide comment
@telephon

telephon Feb 4, 2018

Member

I'd suggest the following: for now, I don't change the names, but when we make the next version step from 3.9 to 3.10, we do the breaking change. I could open an issue with that milestone, so we don't forget.

We could use that as an occasion to fix as many similar cases as possible.

Member

telephon commented Feb 4, 2018

I'd suggest the following: for now, I don't change the names, but when we make the next version step from 3.9 to 3.10, we do the breaking change. I could open an issue with that milestone, so we don't forget.

We could use that as an occasion to fix as many similar cases as possible.

@brianlheim

This comment has been minimized.

Show comment
Hide comment
@brianlheim

brianlheim Feb 4, 2018

Member

I'd suggest the following: for now, I don't change the names, but when we make the next version step from 3.9 to 3.10, we do the breaking change.

This is already milestoned as 3.10... should it not be?

We could use that as an occasion to fix as many similar cases as possible.

If the policy is that we can always make breaking changes in a minor release, I don't see why we would need (or want) to group them.

Member

brianlheim commented Feb 4, 2018

I'd suggest the following: for now, I don't change the names, but when we make the next version step from 3.9 to 3.10, we do the breaking change.

This is already milestoned as 3.10... should it not be?

We could use that as an occasion to fix as many similar cases as possible.

If the policy is that we can always make breaking changes in a minor release, I don't see why we would need (or want) to group them.

@telephon

This comment has been minimized.

Show comment
Hide comment
@telephon

telephon Feb 4, 2018

Member

In the past, such smaller breaking changes have often happened in minor releases. The major releases (sc1, sc2, sc3) were different: they basically broke everything.

If we want to change this, we need to speed up with major releases, otherwise we get stuck.

Member

telephon commented Feb 4, 2018

In the past, such smaller breaking changes have often happened in minor releases. The major releases (sc1, sc2, sc3) were different: they basically broke everything.

If we want to change this, we need to speed up with major releases, otherwise we get stuck.

@telephon

This comment has been minimized.

Show comment
Hide comment
@telephon

telephon Feb 18, 2018

Member

what should we do? Merge it to develop as it is now?

Member

telephon commented Feb 18, 2018

what should we do? Merge it to develop as it is now?

@telephon telephon added the API change label Feb 23, 2018

@telephon

This comment has been minimized.

Show comment
Hide comment
@telephon

telephon Feb 23, 2018

Member

Is that ok to go into develop?

Member

telephon commented Feb 23, 2018

Is that ok to go into develop?

@telephon telephon merged commit eabd21d into supercollider:develop May 12, 2018

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@snappizz

This comment has been minimized.

Show comment
Hide comment
@snappizz

snappizz Jul 13, 2018

Member

i'm a little dissatisfied with this loadToFloatArray/getToFloatArray API, one only working for local servers and one working for all servers but unreliably. i don't really dig the names either, the differences between them is not obvious.

would it make sense for Function:plot to call loadToFloatArray if the server is local and getToFloatArray if the server is remote?

if that's the case, could the get/load dichotomy be abstracted in the Buffer class? and also, let's take this opportunity to rename these methods so it's easier to tell what they're doing.

  • Buffer:getContentsWithSoundFile uses b_write.
  • Buffer:getContentsOverOSC uses repeated calls to /b_getn.
  • Buffer:getContents, which calls Buffer:getContentsWithSoundFile if the server is local and Buffer:getContentsOverOSC otherwise

so just by calling Buffer:getContents, the best retrieval method is selected for you.

Member

snappizz commented Jul 13, 2018

i'm a little dissatisfied with this loadToFloatArray/getToFloatArray API, one only working for local servers and one working for all servers but unreliably. i don't really dig the names either, the differences between them is not obvious.

would it make sense for Function:plot to call loadToFloatArray if the server is local and getToFloatArray if the server is remote?

if that's the case, could the get/load dichotomy be abstracted in the Buffer class? and also, let's take this opportunity to rename these methods so it's easier to tell what they're doing.

  • Buffer:getContentsWithSoundFile uses b_write.
  • Buffer:getContentsOverOSC uses repeated calls to /b_getn.
  • Buffer:getContents, which calls Buffer:getContentsWithSoundFile if the server is local and Buffer:getContentsOverOSC otherwise

so just by calling Buffer:getContents, the best retrieval method is selected for you.

@telephon

This comment has been minimized.

Show comment
Hide comment
@telephon

telephon Jul 13, 2018

Member

@snappizz could you please open a new issue for that? I agree that the names are not so good, but they have been around for decades and this is something separate from the current glitch that needs to be fixed.

Member

telephon commented Jul 13, 2018

@snappizz could you please open a new issue for that? I agree that the names are not so good, but they have been around for decades and this is something separate from the current glitch that needs to be fixed.

@telephon

This comment has been minimized.

Show comment
Hide comment
@telephon

telephon Jul 13, 2018

Member

would it make sense for Function:plot to call loadToFloatArray if the server is local and getToFloatArray if the server is remote?

possible. As a first step, getToFloatArray should work in plot, then I'd try and abstract this out.

Member

telephon commented Jul 13, 2018

would it make sense for Function:plot to call loadToFloatArray if the server is local and getToFloatArray if the server is remote?

possible. As a first step, getToFloatArray should work in plot, then I'd try and abstract this out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment