Hi (again today)
i know that the GUI is still in construction and some new features are coming…
i just get the feedback that a couple of points can be evaluate and maybe fix in the future:
the anchors of the panels are hard to grab sometimes, they are very thin in fact… can we improve the width of the anchor zone ?
well, gui color custom prefs… this is something i have seen from various users
the commands of commenting/uncommenting as toolbar buttons and alt-click
memory/processing usage indicator, to feel the limitation before it is too late
less synth, but with more options (e.g. basic waveforms whould include a shape selector at the place of independant synthdefs. … not sure about this one, as i (personnaly) like the minimalism.
play/stop/kill independently for each buffer as well as a general play/stop
a main mixer module (tracks can be added on the fly at the time we connect a loop/thread output (e.g. mix_in: 1… in every synth/sampler) … again not sure as i use amp: variables to mix, but sometimes, it is nice to get a gain per sound types, this can apply to sub-mix groups as outputs concepts for the master section.
notes: actually, there is more… but as i know more and more this forum, i now get the point of “priorization”, from the dev team and sam. well, i wanted to share what they said around me… and what i think is relevant also
some of these sound like interesting ideas for discussion for new features. Probably the best place for that is GitHub - perhaps creating an issue for each. @ethancrawford might have better ideas on how to capture these as feature requests. We’ve been discussing a system for that possibly based around the SuperCollider RFC approach here: GitHub - supercollider/rfcs
However, even if we were to accept an RFC its implementation really depends on finding people prepared to work on it.
Hi Sam, thanks for your answer… looks interesting. Yes the github is the plateform, i can create a new ITS for each of the topic, can be easy.
Anyway, all of the point mentioned earlier can be implemented by myself at one point if we agree that :
you feel that it is the way to go
the feature is useful for kids and not a distraction for adult
it is not use of other libs (no more)
it gives more flexibility during live coding session (hard core ones)
any, i am looking at those points and check around myself if they feel the need of them and how thyey consider it should be implemented, also we can discuss on github, but i like this forum already
I think they’ll be easier to be discussed individually and hopefully making a single source of feature requests and discussions will make it easier to deal with duplicate similar requests
Also - totally agreed with all of your constraints. That’s exactly the kind of lens we need to be looking though when considering features.
