On 05/22/2014 12:48 PM, Tobias Doerffel wrote:
> Yes, this is probably somewhat broken as VeSTige responds to MIDI
> events only and does not overload playNote() & friends. That way MIDI
> NoteOn/NoteOff events generated inside the NotePlayHandles are
> forwarded to the VST plugin. In the NotePlayH
Hi,
2014-05-18 22:37 GMT+02:00 Vesa :
> Speaking of, it seems that the VST frame delta isn't being set correctly
> maybe? Grejppi said on IRC that he tested it and that the offset
> parameter that gets passed to Vestige is always 0... could be that we're
> looking at the wrong part there, but...
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
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
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
Tres Finocchiaro wrote
> @musicbear,
> Can you please open an issue regarding the LFO controller on the GitHub
> bug
> tracker?
Will do
--
View this message in context:
http://linux-multimedia-studio-lmms.996328.n3.nabble.com/Problem-with-model-step-and-studies-in-sample-exact-controls-tp8814
@musicbear,
Can you please open an issue regarding the LFO controller on the GitHub bug
tracker?
-Tres
- tres.finocchi...@gmail.com
On Fri, May 16, 2014 at 10:51 AM, Vesa wrote:
> On 05/16/2014 04:54 PM, Tres Finocchiaro wrote:
> > @Vesa,
> >
> > Since musicbear's request may be off-topic, c
On 05/16/2014 04:54 PM, Tres Finocchiaro wrote:
> @Vesa,
>
> Since musicbear's request may be off-topic, can/should we open a bug
> report on the LFO controller or would you rather make mental note and
> address it at the same time?
>
Go ahead and open an issue, I have lots on my plate and I can't
On 05/16/2014 01:01 PM, musikbear wrote:
> woo - this is serious interesting. Perhaps this also could make lmms able to
> use the LFO speed in sweeps! (one of the best sweep sounds! Now, any atempt
> to automate SPD, creates horrible artefacts.
That's probably a separate problem - I suspect that
On 05/16/2014 12:46 PM, Raine M. Ekman wrote:
> Citerar Vesa :
>> Part of the problem is no
>> sample-exactness in playback, but part is because the step size prevents
>> gradual change so that even with sample-exactness the problem still
>> exists. Solving this would make peak/LFO controllers much
woo - this is serious interesting. Perhaps this also could make lmms able to
use the LFO speed in sweeps! (one of the best sweep sounds! Now, any atempt
to automate SPD, creates horrible artefacts. That could originate from that
problem.) Whitch model.. I fear that there are pro and cons for all,
Citerar Vesa :
> Part of the problem is no
> sample-exactness in playback, but part is because the step size prevents
> gradual change so that even with sample-exactness the problem still
> exists. Solving this would make peak/LFO controllers much more useful
> and flexible, as you could connect th
On 05/16/2014 12:34 AM, Tres Finocchiaro wrote:
>
> I'm very glad this is being brought up.
>
> Option 2 reads the most beneficial whereas Option 1 reads the most
> unobtrusive from a coding perspective.
>
> From you experience, do plugins/instruments/controls/etc which require
> strict step values
I'm very glad this is being brought up.
Option 2 reads the most beneficial whereas Option 1 reads the most
unobtrusive from a coding perspective.
>From you experience, do plugins/instruments/controls/etc which require
strict step values generally rely on the GUI for proper strict values, or
do th
On 05/15/2014 05:31 PM, Vesa wrote:
> So I've come up with some ideas on solving this dilemma.
>
> 1. Interpolate all volume controls (and others where similar issues
> exist) - so that volume transitions would always be smooth and not
> sudden: when the volume is changed, it slides from oldvalue
So, each automatable model has a "step size" property, which is used for
determining the accuracy of the knobs. A step size of 0.1 causes the
knob values to move in 0.1 increments, a step size of 1 causes the knob
to only move between integer values, and so on.
This is of course good for user conv
24 matches
Mail list logo
