Hi,
sorry, I thought I have said it. The feature will be removed. Instead, I will
code ZASF in Qt (this can take a while) and port the FX to ladspa.
Note that the NRPNS were only for FX anyways, so no need to wait for the new
GUI if you want this feature.
Regards,
Johannes
> Any news on that
Cant they just be tagged as outdated or something of the sort? That way we
dont need to delete them. that is how the ubuntu community help wiki does
it.
On Sun, May 18, 2014 at 9:45 PM, Stian Jørgensrud wrote:
> I don't want to make a difference on 1.0, 1.1 or any 1.X and perhaps not on
> any fu
I second this. Lack of easy automation has limited my use of ZynAddSubFx...
Kind regards,
Sam Duff
On Mon, May 19, 2014 at 7:02 AM, Tobias Doerffel
wrote:
> 2013-06-21 14:05 GMT+02:00 [Zyn]Johannes :
> > as far as I see, the LMMS remote version ZynAddSubFX does not support
> NRPNs,
> > only th
Oh, yes, I only tried in the song editor, sorry. We should definitely make
it faster in the piano roll!
I somehow missed that this is about the piano roll. Dragging would be
perfectly OK there ;)
So, how about doing both?
2014-05-18 23:19 GMT+02:00 Vesa :
> On 05/19/2014 12:17 AM, Lukas W. wrot
2014-05-18 23:19 GMT+02:00 Vesa :
>
> Certainly not in the piano roll? No one was talking about song editor
> here, as the middle button is already taken in song editor anyway...
>
> For me, shift-scrolling in piano roll is way too slow...
I agree here however modifying PianoRoll::wheelEvent() sho
On 05/19/2014 12:17 AM, Lukas W. wrote:
> Slow? It's not slow on my system. 4 bars per wheel step. I can scroll
> ~45 bars with one strike.
> If you want to scroll faster, using the scrollbar becomes the most
> efficient way, dragging can't beat this.
>
Certainly not in the piano roll? No one was
Slow? It's not slow on my system. 4 bars per wheel step. I can scroll ~45
bars with one strike.
If you want to scroll faster, using the scrollbar becomes the most
efficient way, dragging can't beat this.
2014-05-18 23:12 GMT+02:00 Vesa :
> On 05/19/2014 12:04 AM, Lukas W. wrote:
>
> > Also - pa
On 05/19/2014 12:04 AM, Lukas W. wrote:
> > Also - panning a piano roll, bb editor or song editor with
> middlemouse drag and drop would be super effective and fast. Bleder
> does it. Going for the scroll bars takes a lot if time.
> Try holding your shift key while scrolling. That's how it's usuall
> Also - panning a piano roll, bb editor or song editor with middlemouse
drag and drop would be super effective and fast. Bleder does it. Going for
the scroll bars takes a lot if time.
Try holding your shift key while scrolling. That's how it's usually done,
so I think we should stick with the stan
2013-06-21 14:05 GMT+02:00 [Zyn]Johannes :
> as far as I see, the LMMS remote version ZynAddSubFX does not support NRPNs,
> only the registered (see http://zynaddsubfx.sourceforge.net/doc_3.html here
> ). I think they are very useful for automation. Some of them seem to work
> good. Allowing this
2014-02-12 23:09 GMT+01:00 Tobiasz Karoń :
> Some mice allow horizontal motion od their wheels its very good for
> scrolling piano rolls and other data charts. Could we make LMMS respond to
> these along with the vertical?
Doesn't Qt automatically cover this by scrolling the according
horizontal s
On 05/18/2014 11:39 PM, Tobias Doerffel wrote:
> 2014-04-06 11:19 GMT+02:00 Vesa :
>> I think this might be faster than reading values from a method one by
>> one. Instead of calling a method in automatablemodel (which maybe calls
>> other functions) per-frame, we could just retrieve a buffer of va
2014-04-06 11:19 GMT+02:00 Vesa :
> I think this might be faster than reading values from a method one by
> one. Instead of calling a method in automatablemodel (which maybe calls
> other functions) per-frame, we could just retrieve a buffer of values
> from the model, per-period. Also this way, we
2014-04-06 11:19 GMT+02:00 Vesa :
> Tell me does the following make sense:
>
> - AutomatableModel contains a pointer to a buffer
> - When a controller is connected to a model, it gets passed that buffer
> pointer
> - new buffer is created at connection time (deleted when connection is
> disconnecte
On 05/18/2014 11:34 PM, Tobias Doerffel wrote:
> 2014-05-18 20:20 GMT+02:00 Vesa :
>> Hm. Could we not implement something similar for our own MIDI-based
>> instruments?
> Just recognized that we already pass a MidiTime object to
> Instrument::handleMidiEvent() (which is implemented by some MIDI-ba
2014-05-18 20:20 GMT+02:00 Vesa :
> Hm. Could we not implement something similar for our own MIDI-based
> instruments?
Just recognized that we already pass a MidiTime object to
Instrument::handleMidiEvent() (which is implemented by some MIDI-based
instruments) so we could add an additional offset
I don't want to make a difference on 1.0, 1.1 or any 1.X and perhaps not on
any future LMMS versions unless there is a huge difference like there was
from 0.4 to 1.0.
I agree that there perhaps aren't any reasons to keep the old pages, no
other than for fun and history. If it is a way to keep them
On 05/18/2014 09:10 PM, Tobias Doerffel wrote:
> 2014-05-18 19:46 GMT+02:00 Vesa :
>> Hmm. How do VST instruments in other DAWs handle this?
> The VstMidiEvent structure has a "deltaFrames" field (where we also
> put our offset in).
Hm. Could we not implement something similar for our own MIDI-bas
2014-05-18 19:46 GMT+02:00 Vesa :
> Hmm. How do VST instruments in other DAWs handle this?
The VstMidiEvent structure has a "deltaFrames" field (where we also
put our offset in).
> Oh, so the offset applies for the entire note. I figured it'd work by
> just shortening the first period and adding
On 05/18/2014 08:33 PM, Tobias Doerffel wrote:
> Yes, AFAIK there's no way to add an offset information to MIDI events.
> The only solution here is to use as small buffer/period sizes as
> possible.
Hmm. How do VST instruments in other DAWs handle this? Afaik VST
instruments use MIDI, but I'm pre
2014-05-18 18:33 GMT+02:00 Vesa :
> It seems like native instruments have a way of adding offset to the
> first period of the note event, so that if they start in the middle of a
> period, their timing is still accurate. For MIDI-instruments, this
> offset doesn't get properly communicated all the
One more thing... recently, grejppi found out that the timing of
MIDI-based instruments isn't as accurate as the timing of native
nph-based instruments.
It seems like native instruments have a way of adding offset to the
first period of the note event, so that if they start in the middle of a
peri
The advantages are mostly add-free downloads, and proper domain/site
integration. If we keep sourceforge (which I'm personally not entirely
against) any domain we buy would have to redirect there, sort of negating
the idea of having our own domain (right?)
Again, I personally have no issues with
2014-05-18 17:59 GMT+02:00 Vesa :
> Additionally, somewhat related to this and other recent developments, I
> propose removing the options "sample-exact controllers" and
> "anti-aliasing oscillators" from the export dialog. The reason being:
I fully agree. I once introduced these for the initial e
Additionally, somewhat related to this and other recent developments, I
propose removing the options "sample-exact controllers" and
"anti-aliasing oscillators" from the export dialog. The reason being:
- Anti-aliasing oscillators currently does nothing. However, we already
have the implementation
On 05/18/2014 05:49 PM, Tobias Doerffel wrote:
>> 2. Make the step size only affect the knobs, and possibly the automation
>> grid, but allow the actual values of the model to also go between steps.
>> Maybe make this behaviour configurable per-model, add a flag or
>> something that determines how
Hi Vesa & all,
Foreword: the current properties of AutomatableModel like min, max,
step size etc. date back to when we did the model/view split. Step
size hasn't been seen as a view-specific property as it was directly
related to altering data (values) and thus got moved to the model.
2014-05-15
Hi Jonathan,
thanks for your research!
2014-05-17 8:35 GMT+02:00 Jonathan Aquilina :
> Webareas for lmms
>
> MySQL DBs for lmms
>
> PostgreSQL DBs for lmms
That's it I think. For everything else we have Github and Sourceforge
and I clearly see no reason why we should move away from well working
Stian Jørgensrud wrote
> Here are the Opulenz page:
> http://lmms.sourceforge.net/wiki/index.php/Opulenz
Very nice. informative and well explained!
--
View this message in context:
http://linux-multimedia-studio-lmms.996328.n3.nabble.com/Wiki-revival-tp8762p8848.html
Sent from the lmms-deve
29 matches
Mail list logo
