I prefer this to the old, as it is much cleaner - it's looking good, while
the old one to me looks unconsistent, blurry and simply poor quality.
Nice warm colors.
2014-02-09 16:43 GMT+01:00 Bill Y. :
> Thoughts, comments, feedback.
>
>
> https://drive.google.com/file/d/0BwJ-TpACk7OsZ0JwRjRwd3pwR
> Of course an option would be the best solution but for the time being,
> hardcoding the property for some models (like freq knobs) is less
> work. However feel free to implement an according context menu action.
> A hardcoded property still could be used as a hint for the default
> setting for va
On 02/10/2014 08:58 PM, Tres Finocchiaro wrote:
>
> I don't want pointless "competitions" on mailing lists, with camps
> forming and people taking sides.
>
>
> Vesa, we all appreciate your hard work and organization in getting
> these updates in. Without you leading this initiative we wou
2014-02-10 19:56 GMT+01:00 Johannes Lorenz :
> So you mean to bind the property to a model (instead of a connection, like I
> proposed)? This would restrict the user to not use two scale types to control
> one model (i.e. one logarithmic, one linear). Does anyone think this
> restriction is too res
I've been thinking about the idea of using the case as the model for
graphics, and I think there's some fundamental things missing from any
of the current drafts.
Firstly, some things that have already been discussed, such as texture,
etc.
Secondly, the knobs and buttons would have to be done in
>
> I don't want pointless "competitions" on mailing lists, with camps
> forming and people taking sides.
Vesa, we all appreciate your hard work and organization in getting these
updates in. Without you leading this initiative we wouldn't be having
these great conversations.
That said, when yo
Thanks for your help, Toby. A few questions are left:
> I
> propose to add a boolean property to AutomatableModel which indicates
> whether the model represents a linear or logarithmic value - or even
> more generic, an enumeration which could include further progression
> formulas in the future.
On 02/10/2014 06:36 PM, Bill Y. wrote:
> I don't like this direction, and here are my reasons:
>
> 1. The sid emulator font is a bit map font on the commodore label area
> of the banner. The font is not unique. We are already using a similar
> font for Bit Invade where it makes sense. Like Freeboy
>
> Tres, you're again reading way too much into what I've said
>
Perhaps we are both reading in to what each other is saying. There's no
reason to make assumptions about eachother's thoughts and I'm sorry if I've
illustrated this here.
I (as well as many others) like Bill's work and I thought I
I don't like this direction, and here are my reasons:
1. The sid emulator font is a bit map font on the commodore label area of
the banner. The font is not unique. We are already using a similar font for
Bit Invade where it makes sense. Like Freeboy Color logo, the Sid logo
should capture the comm
On 02/10/2014 05:58 PM, Tres Finocchiaro wrote:
> For what it is worth, I think it could go with or without the screen
> font.
>
> It is a nice touch, but with some minor visibility changes, I think
> Bill's original rendering is fantastic.
>
> Besides punitive reasons for not following protocol, i
For what it is worth, I think it could go with or without the screen font.
It is a nice touch, but with some minor visibility changes, I think Bill's
original rendering is fantastic.
Besides punitive reasons for not following protocol, is there a reason why
we shouldn't have Bill tweak his and ge
On 02/10/2014 02:22 PM, Emilio Coppola wrote:
> When you are finished destroying that I want the Bill Y. version... If
> possible
What are you talking about, what do you mean "destroying"? Who's
destroying what? Speak clearly.
--
More throwing ideas about: here's a frame and buttons done entirely in
PETSCII, ie. C-64 character map symbols.
In other words, an interface like this is something you might have seen
in a C-64 music composition software (those actually existed!)
-
14 matches
Mail list logo
