Hey guys
For inspiration my i suggest looking at the mixxx program. They have buttons
similar to what Vesa is invisioning.
On Monday, February 10, 2014 09:31:10 AM Vesa wrote:
> Here's a little mockup of what I envision would capture the spirit of
> the C-64:
>
>
>
> This is just an example,
Here's a little mockup of what I envision would capture the spirit of
the C-64:
This is just an example, and the knobs could be made differently, or a
different colour used (we have 16 options!) but it shows the general
idea: C-64 font, no antialiasing for anything, black background... the
knobs
I really like the changes and agree with many points.
The beige color I find very representative.
The old style knobs are a great touch but the polished glare effect sort of
hides the black line and should have some more contrast.
I agree with both sides of this argument on many points, but hope
Here's what I'm approximately thinking for the title part, although the
image still needs some retouching and work...
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer
On 02/09/2014 10:21 PM, Vesa wrote:
>
> I think we should definitely keep the style of the title of the old
> plugin, but make it nicer. The photorealistic image of a C-64 surface I
> think is a good enough idea to keep, I think we should look for a better
> bitmap font though, one that's an authen
On 02/09/2014 09:46 PM, Bill Y. wrote:
> >Apart from you not following the 1st rule of project guidelines, I'm
> just not feeling it.
>
> First off It's not committed to any branch. Secondly in my
> introduction thread when I explained that I felt Mallets and the Sid
> Emulator art work needed to b
>Apart from you not following the 1st rule of project guidelines, I'm just
not feeling it.
First off It's not committed to any branch. Secondly in my introduction
thread when I explained that I felt Mallets and the Sid Emulator art work
needed to be reworked, it was pointed out that neither were o
Hi,
first of all thanks a lot for your initial efforts on this feature! 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
Hi,
just one note: a LADSPA plugin will not be more stable just because it
is a LADSPA plugin. It's regular C/C++ code and if you mess things up,
it will crash, no matter inside which kind of plugin the code is
running. A crashing LADSPA plugin will also crash LMMS itself as it's
not running in a
Yes, it'd be a good thing to have all of our widgets available in Qt
Designer so we can replace lots of code with code that is generated
from the UI files. Do you have ambitions for implementing this, you're
welcome to do so :-)
However I disagree about the specializations. Properties like "number
On 02/09/2014 06:45 PM, Vesa wrote:
> On 02/09/2014 05:43 PM, Bill Y. wrote:
>> Thoughts, comments, feedback.
>>
>> https://drive.google.com/file/d/0BwJ-TpACk7OsZ0JwRjRwd3pwREk/edit?usp=sharing
> https://github.com/diizy/lmms/issues/1
Apart from you not following the 1st rule of project guidelines
On 02/09/2014 05:43 PM, Bill Y. wrote:
> Thoughts, comments, feedback.
>
> https://drive.google.com/file/d/0BwJ-TpACk7OsZ0JwRjRwd3pwREk/edit?usp=sharing
https://github.com/diizy/lmms/issues/1
--
Managing the Performance o
Quoting "Bill Y." :
> Thoughts, comments, feedback.
>
> https://drive.google.com/file/d/0BwJ-TpACk7OsZ0JwRjRwd3pwREk/edit?usp=sharing
>
Pretty nice. The buttons could IMO have a clearer indication of state,
e.g. the selected waveform is much easier to spot in the old artwork.
--
ra...@iki.fi
On 02/09/2014 05:39 PM, Bill Y. wrote:
> I guess I could do that. Do we actually want a green vintage knob, or
> are we replacing that with a vintage knob that could be used else
> ware? Also if the later option should I call it something other than
> knob_green, or is it easier to keep it the exis
Love it. Text may be hard to read from a distance, but easy fix if it is.
Very nice work. Is there a new logo too?
On Feb 9, 2014 10:48 AM, "Emilio Coppola" wrote:
> It is amazing!! :D
>
>
> 2014-02-09 16:43 GMT+01:00 Bill Y. :
>
>> Thoughts, comments, feedback.
>>
>>
>> https://drive.google.co
It is amazing!! :D
2014-02-09 16:43 GMT+01:00 Bill Y. :
> Thoughts, comments, feedback.
>
>
> https://drive.google.com/file/d/0BwJ-TpACk7OsZ0JwRjRwd3pwREk/edit?usp=sharing
>
>
> --
> Managing the Performance of Cloud-Bas
Thoughts, comments, feedback.
https://drive.google.com/file/d/0BwJ-TpACk7OsZ0JwRjRwd3pwREk/edit?usp=sharing
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Comm
I guess I could do that. Do we actually want a green vintage knob, or are
we replacing that with a vintage knob that could be used else ware? Also if
the later option should I call it something other than knob_green, or is it
easier to keep it the existing name even if it's not green?
On Sat, Feb
Using mouse to resize the waveform in 0.4.15 confirmed works. Not cool to
disable it "because they had some issues apparently" - diiz.
--
View this message in context:
http://linux-multimedia-studio-lmms.996328.n3.nabble.com/Plugins-to-update-tp6152p6183.html
Sent from the lmms-devel mailing li
On Sun, Feb 9, 2014 at 8:25 AM, Johannes Lorenz
wrote:
> Am Samstag, 8. Februar 2014, 17:08:22 schrieb Alexander Liebendorfer:
>> I think logarithmic connections should be included more generally to
>> all the different controllers. The number 1 place where people usually
>> want to use it is with
Closed it as invalid on SF tracker and mentioned that it was an upstream wine
bug
On Sunday, February 09, 2014 12:31:27 PM Vesa wrote:
> On 02/09/2014 12:19 PM, Jonathan Aquilina wrote:
> > Agreed, So I could technically close the bug as not ours then?
>
> Yup.
>
> -
On 02/09/2014 12:19 PM, Jonathan Aquilina wrote:
> Agreed, So I could technically close the bug as not ours then?
>
Yup.
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offe
Agreed, So I could technically close the bug as not ours then?
On Sunday, February 09, 2014 11:00:54 AM Vesa wrote:
> On 02/09/2014 10:40 AM, Jonathan Aquilina wrote:
> > https://sourceforge.net/p/lmms/bugs/573/
> >
> > Basically there seems there is a fix for this issue in terms of the
> > upstr
On 02/09/2014 11:39 AM, Johannes Lorenz wrote:
> Am Sonntag, 9. Februar 2014, 11:33:19 schrieb Vesa:
>> there's things that LADSPA plugins can't do, eg.
>> instruments.
> Sorry for the OT talk. But: I am not sure why this should not be possible. An
> instrument is nothing but an effect with no inp
This topic is half a year old, but can someone please give comments? Do you
think it is useful?
Imo it would be only a few lines of code and would help us to build new UI
widget way faster (and cleaner).
> Hey,
>
> We have many widgets that don't just take a parent. Thus, they can not be
> use
Am Sonntag, 9. Februar 2014, 11:33:19 schrieb Vesa:
> there's things that LADSPA plugins can't do, eg.
> instruments.
Sorry for the OT talk. But: I am not sure why this should not be possible. An
instrument is nothing but an effect with no input and one (stereo) output. I
know this is missing in
On 02/09/2014 11:13 AM, Johannes Lorenz wrote:
>> And for another, I don't really see what the reasoning or purpose behind
>> this LADSPA++ idea is - see my response in the github thread. Let me
>> turn your question around for you: what benefit would LADSPA++ allow
>> over a native LMMS plugin?
>
> And for another, I don't really see what the reasoning or purpose behind
> this LADSPA++ idea is - see my response in the github thread. Let me
> turn your question around for you: what benefit would LADSPA++ allow
> over a native LMMS plugin?
* smaller code (about 5-10 times less)
* safer cod
On 02/09/2014 10:46 AM, Johannes Lorenz wrote:
>> Thanks, this is helpful. The BUILD_PLUGIN is in the main cmake file
>> right? I don't really have experience with cmake, I just barely know how
>> to write regular makefiles, but I guess it's just something I'll figure
>> out as I go, again... (the
On 02/09/2014 10:40 AM, Jonathan Aquilina wrote:
> https://sourceforge.net/p/lmms/bugs/573/
>
> Basically there seems there is a fix for this issue in terms of the upstream
> wine.
>
> The problem is there are no packages in the wine ppa yet and it involved the
> person compiling wine from source
> Thanks, this is helpful. The BUILD_PLUGIN is in the main cmake file
> right? I don't really have experience with cmake, I just barely know how
> to write regular makefiles, but I guess it's just something I'll figure
> out as I go, again... (the best way to figure things out!)
Actually not. This
https://sourceforge.net/p/lmms/bugs/573/
Basically there seems there is a fix for this issue in terms of the upstream
wine.
The problem is there are no packages in the wine ppa yet and it involved the
person compiling wine from source.
I am wondering though if we should include the wine source
On 02/09/2014 10:24 AM, Johannes Lorenz wrote:
> Hey,
>
> seems to be a good idea to me. If you need some sample code about
> waveshaping,
> look into ZynAddSubFX, though I think you know how it's done.
>
> You probably need 6 files:
>
> $ find . -iname "*analy*" | grep -E '\.cpp$|\.h$'
> ./plugi
Hey,
seems to be a good idea to me. If you need some sample code about waveshaping,
look into ZynAddSubFX, though I think you know how it's done.
You probably need 6 files:
$ find . -iname "*analy*" | grep -E '\.cpp$|\.h$'
./plugins/spectrum_analyzer/spectrumanalyzer_control_dialog.cpp
./plugin
34 matches
Mail list logo
