Re: [question] SoundFileView - channel spacing
scott-y6qSm6YX8/[email protected] Wed, 11 Apr 2018 20:48:41 +0000
| Newsgroups | gmane.comp.audio.supercollider.devel |
|---|---|
| Message-ID | <CANmfHJ_wnM5Y6XrPbZiOsSS1eFcbuTS7rONddCLbq9npa6FKFw@mail.gmail.com> |
Doing view layout when some of the spacing is hard-coded-ish and hidden in
the underlying drawing code is a nightmare. What about:
1. SoundFileView channels are drawn with no margin (i.e. butted against the
edge of their rect)
2. Spacing between channels is a user-definable parameter (this should be a
pretty trivial addition)
That way, if you have:
View().layout_(VLayout(
SoundFileView(), SoundFileView(), SoundFileView()
).margin_(20))
... you'll get the margin you requested, rather than an arbitrarily larger
margin (based on the SFV internals) that you have to reverse-engineer.
Calculating the channel rects is simple:
channelHeight = (bounds.height / channels) - spacing;
channelTop = channel * (channelHeight + spacing);
- S
On Wed, Apr 11, 2018 at 1:33 PM <[email protected]> wrote:
> In further work on improving SoundFileView (to be able to use it for
> variety of plotting scenarios) I'm adding the ability to offset the view
> vertically, and also change the spacing between channels.
>
> Currently, SoundFileView displays (n+1) number of spaces for every (n)
> number of channels:
> https://ibb.co/dOAZ1c
> While I think this looks fine, it makes harder to calculate where the
> values on the y axis are (of course it's possible, but arguably convoluted,
> especially in case one wanted to superimpose a gird from sclang on top of
> it, or even label reference values).
> Also, exposing control over spacing would be awkward - either setting
> spacing ratio would result in automatically calculated channel
> height/ratio, or setting channel height would make the spaces automatically
> calculated (in each case the two ratios would not add up to 1).
> I'm thinking about making the top and bottom space half of the current
> value:
> https://ibb.co/iRQ1gc
> Then all the channels are equally distributed inside the view. I think
> it's a more "proper" approach allowing better labeling etc, but I also
> think it looks a little worse than the current implementation.
>
> What are your thoughts?
>
> Thanks,
> Marcin
>