LevelIndicatorStyle bug in sc3.9.0-rc2?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

LevelIndicatorStyle bug in sc3.9.0-rc2?

Fredrik Olofsson
hi list,
in 3.9 rc2 many if not most of the examples in LevelIndicator helpfile are semi-broken.

like this one...
(
w = Window().front.layout_(
    HLayout(
        LevelIndicator().style_(\continuous).value_(1/3),
        LevelIndicator().style_(\led).value_(2/3),
)
)
)

the led style is not set and this is posted...
Qt: WARNING: Do not know how to use an instance of class 'Meta_QLevelIndicatorStyle'

to fix it i guess that in QLevelIndicatorStyle this...
*new { arg style; style.isInteger.if(style, { this.perform(style) }) }
really should be...
*new { arg style; style.isInteger.if(style, { ^this.perform(style) }) }
that makes the examples work again on my osx machine.

not critical and my old sc3.7 version have the same issue.  strange that no one saw it no?
but if  this is the correct fix shall i make a pull request?  which branch?
thanks,
_f

  #|
     fredrikolofsson.com     musicalfieldsforever.com
  |#


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: LevelIndicatorStyle bug in sc3.9.0-rc2?

Fredrik Olofsson
> Qt: WARNING: Do not know how to use an instance of class 'Meta_QLevelIndicatorStyle'
>
> to fix it i guess that in QLevelIndicatorStyle this...
> *new { arg style; style.isInteger.if(style, { this.perform(style) }) }
> really should be...
> *new { arg style; style.isInteger.if(style, { ^this.perform(style) }) }
> that makes the examples work again on my osx machine.

the real fix should probably be...
*new { arg style; style.isInteger.if({ ^this.perform(#[\continuous, \led][style]) }, { ^this.perform(style) });}
or shorter...
*new { arg style; ^this.perform( style.isInteger.if({ #[\continuous, \led][style] }, style ) ); }
to also make sure that the old style style works.
_f

  #|
     fredrikolofsson.com     musicalfieldsforever.com
  |#


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: LevelIndicatorStyle bug in sc3.9.0-rc2?

patrick
In reply to this post by Fredrik Olofsson

Hi Fredrik,


Thanks for testing! I'm adding this to the list of known issues in 3.9.0.


You can create a branch with this fix in your fork of SuperCollider. Then, you can create a pull request for that branch against SuperCollider's develop branch (the default branch). It is possible to point a PR towards a different branch after the fact using GitHub's web interface. For example, merging this change into the 3.9 branch, once 3.9.0 is released, will include it in the next 3.9.x patch release.


Cheers,

Patrick

Reply | Threaded
Open this post in threaded view
|

Re: LevelIndicatorStyle bug in sc3.9.0-rc2?

Nathan Ho
On 2018-01-08 15:39, [hidden email] wrote:

> Hi Fredrik,
>
> Thanks for testing! I'm adding this to the list of known issues in
> 3.9.0.
>
> You can create a branch with this fix in your fork of SuperCollider.
> Then, you can create a pull request for that branch against
> SuperCollider's develop branch (the default branch). It is possible to
> point a PR towards a different branch after the fact using GitHub's
> web interface. For example, merging this change into the 3.9 branch,
> once 3.9.0 is released, will include it in the next 3.9.x patch
> release.

hi patrick,

careful though... if you base a commit off the develop branch, merging
that branch into 3.9 merges all the other stuff from develop into 3.9!

the best strategy is to merge 3.9-based commits into 3.9 and merge
develop-based commits into develop. (if something is incorrectly
directed, we can change the base branch.) if a bugfix commit is based on
develop that should go into 3.9, it can be cherrypicked onto 3.9 after
the merge, and then 3.9 should be quickly merged back into develop to
pacify any fear of conflicts. patch authors do not need to learn this
process, it can all be taken care of by people more familiar with the
git workflow.


nathan

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/