I see. But the basic functions of a Lv2 synth would work?
Per-note bends/pitch - I wish ZynAddSubFX could do it too...
On 19 Jan 2014 00:26, "Vesa" wrote:
> On 01/19/2014 01:05 AM, Tobiasz Karoń wrote:
> >
> > Does this mean that we could... say... use TripleOscilator with Ardour?
> >
>
> Ardour
On 01/19/2014 01:05 AM, Tobiasz Karoń wrote:
>
> Does this mean that we could... say... use TripleOscilator with Ardour?
>
Ardour uses MIDI for all instruments, so you couldn't do things that
tripleosc currently supports, like per-note pitch bends, per-note
panning...
---
Does this mean that we could... say... use TripleOscilator with Ardour?
On 18 Jan 2014 16:27, "Tobias Doerffel" wrote:
> Sure we can but I'm thinking about Paul's proposal to convert all our
> existing plugins to LV2.
>
>
>
>
> -
LV2 can probably be made to support that by writing an extension -- if one
doesn't exist already.
2014/1/18 Vesa
> On 01/18/2014 05:26 PM, Tobias Doerffel wrote:
> > Sure we can but I'm thinking about Paul's proposal to convert all our
> > existing plugins to LV2.
>
> Hmm. Would it break any ex
On 01/18/2014 05:26 PM, Tobias Doerffel wrote:
> Sure we can but I'm thinking about Paul's proposal to convert all our
> existing plugins to LV2.
Hmm. Would it break any existing functionality? Does LV2 support eg.
per-note pitch bends? I know MIDI doesn't support those, and if LV2 is
(like VST) b
Sure we can but I'm thinking about Paul's proposal to convert all our
existing plugins to LV2.
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Crit
On 01/18/2014 01:44 PM, Tobias Doerffel wrote:
> Hi Paul,
>
> just had the time to read your docs regarding Unison design and I
> really like it. As an abstract description it's very similiar to how
> LMMS is supposed to work in the future (especially the resources
> section). I don't know whether
Hi,
2014/1/16 Tres Finocchiaro
> Coming from the windows side of composition, the VST performance on
> playback is something that suffers currently.
>
Has this been an issue since a specific version? Generally the current
approach (launching the VST plugin in a separate process) is very portab
Hi Paul,
just had the time to read your docs regarding Unison design and I really
like it. As an abstract description it's very similiar to how LMMS is
supposed to work in the future (especially the resources section). I don't
know whether to agree or disagree about the migration to LV2 as I don't
vesa I think the migration to unison should be started on. It is going to
take a lot of work for Paul to migrate it so we will have time to work on
new releases while he works on the migration to the new core.
On Thu, Jan 16, 2014 at 8:40 AM, Vesa wrote:
> On 01/16/2014 09:22 AM, Johannes Loren
Coming from the windows side of composition, the VST performance on
playback is something that suffers currently. Setting the vst process
priority above LMMS helps considerably, bit this chopping and latency is
something that can drastically change the experience when composing.
-Tres
On Jan 16,
On 01/16/2014 09:22 AM, Johannes Lorenz wrote:
>> I don't think I'd be much use in it, I'd rather continue doing the UI
>> work where I actually have a chance of doing something useful.
>>
>> I also don't think it'd be a good idea right now to start porting in a
>> new engine if it means we have to
> I don't think I'd be much use in it, I'd rather continue doing the UI
> work where I actually have a chance of doing something useful.
>
> I also don't think it'd be a good idea right now to start porting in a
> new engine if it means we have to put everything else on hold.
Agreeing. RT safety
Paul, thank you so much for this update - it's heartwarming.
I'll stay out of your way and focus on graphics and other matters, but I so
much would like to help integrating Unison core quickly. I'm no good as a
programmer though.
Be unstoppable!
On 15 Jan 2014 18:12, "Paul Giblock" wrote:
> If
He has just mentioned to me and others on irc there has been some bit rot
to unison but nothing that cannot be fixed. as it has gone untouched for
the last two years.
Paul i would like to offer my services with QA and testing. and I am sure
alot of other users here would like to do the same.
On
Tobias:
Thanks for your input! I know I contacted you regarding the Unison-Studio
endeavor several years back (3?? Wow, time flies!) You are the main person
holding LMMS together at this point, so I definitely do not want to
distract you from keeping LMMS usable and integrating contributions from
Hi,
2014/1/15 Paul Giblock
> Another thing that really bothered me about LMMS is that the projects are
> huge monolithic beasts. Therefore, I have additional thoughts regarding
> next-genreation project files, resource management, and a "proper"
> extension system. Essentially, projects are just
On 15 January 2014 22:42, Paul Giblock wrote:
>
> The bulk of the work above is already complete. The big task is taking LMMS
> elements and implementing them in terms of components.
>
> Another thing that really bothered me about LMMS is that the projects are
> huge monolithic beasts. Therefore,
On Wed, Jan 15, 2014 at 4:00 PM, Jonathan Aquilina
wrote:
> I have noticed some discussion about the above topic on the list in recent
> days.
>
Yep :)
> written a new engine called unison that is real time safe
>
Is the code online? The unison.sf.net page doesn't have code.
I have just spoken
If people are interested in working on UI code and they are not up for work
on the DSP core, then I fully support the decision to keep working on UI
changes. I do not want to disturb any momentum in order to work on a major
change which may turn to vaporware anyway. There is still a lot to benefi
PNG files should not oppose the modernisation.
On 15 Jan 2014 17:44, "Jonathan Aquilina" wrote:
> If you want to focus on UI work there really isnt anything stopping you
> with
> this migration. It requires just having the various and all aspects
> connecting
> to unison and working with it.
>
>
If you want to focus on UI work there really isnt anything stopping you with
this migration. It requires just having the various and all aspects connecting
to unison and working with it.
On Wednesday 15 January 2014 18:28:28 Vesa wrote:
> On 01/15/2014 06:00 PM, Jonathan Aquilina wrote:
> > Woul
If waiting longer with replacing the core means it will cost more work
later and rewriting code you've just wrote, it'd be best to do it ASAP.
On 15 Jan 2014 17:29, "Vesa" wrote:
> On 01/15/2014 06:00 PM, Jonathan Aquilina wrote:
> > Would you guys be willing to step back from other work such as
On 01/15/2014 06:00 PM, Jonathan Aquilina wrote:
> Would you guys be willing to step back from other work such as UI work to
> contribute to this endeavour?
I don't think I'd be much use in it, I'd rather continue doing the UI
work where I actually have a chance of doing something useful.
I also
I'd say: go for it!
On 15 Jan 2014 17:16, "Jonathan Aquilina" wrote:
> Just keep on working and do what Unfa's do best hehe. I guess UI work
> really
> wont need to stop.
>
> We just need man power to rewire the bits of LMMS to work with the unison
> engine.
>
> On Wednesday 15 January 2014 17:13
Just keep on working and do what Unfa's do best hehe. I guess UI work really
wont need to stop.
We just need man power to rewire the bits of LMMS to work with the unison
engine.
On Wednesday 15 January 2014 17:13:36 Tobiasz Karoń wrote:
> So it would be best to first focus all manpower on uni
So it would be best to first focus all manpower on unison integration, and
carry on with other issues after we're done with it?
How about people like me who can't help with LMMS code?
On 15 Jan 2014 17:01, "Jonathan Aquilina" wrote:
>
> I have noticed some discussion about the above topic on the
I have noticed some discussion about the above topic on the list in recent
days.
I have spoken to Paul Gibock who has research this issue, and with the current
engine, it would be a near impossibility to make it real time safe. He has
written a new engine called unison that is real time safe, b
28 matches
Mail list logo
