On Friday 19 February 2010 08:42:36 Fons Adriaensen wrote:
> On Fri, Feb 19, 2010 at 04:05:02PM +0300, alex stone wrote:
> > An obvious question i guess, but is 1/16 a fine enough resolution for
> > a wide selection of use cases?
>
> I don't know about any 'human interfaces' (faders, knobs,
> mous
On Sat, Feb 20, 2010 at 7:23 AM, wrote:
> For example it would be quite hairy to use discrete
> events to create a C1 continuous control signal -
> C1 means no 'jumps' and no 'corners'. It can be done
> but would require a level of complexity that breaks
> the charms of the basic idea and would
On Sat, Feb 20, 2010 at 07:31:04AM +0100, torbenh wrote:
> i am basically more in favour of timestamped events.
> but your argumentation in this thread is pretty convincing.
> and timestamped events come with a galore of other problems,
> which i think are harder to tackle in a jack context.
I'll
On Fri, Feb 19, 2010 at 01:48:24PM +0100, Fons Adriaensen wrote:
> On Fri, Feb 19, 2010 at 03:51:22AM +0100, torbenh wrote:
>
> > On Thu, Feb 18, 2010 at 06:09:42PM +0100, f...@kokkinizita.net wrote:
> >
> > > We may not be talking of the same thing. This is not about
> > > 'generic events' but ab
On Fri, Feb 19, 2010 at 02:42:36PM +0100, Fons Adriaensen wrote:
> On Fri, Feb 19, 2010 at 04:05:02PM +0300, alex stone wrote:
>
> > An obvious question i guess, but is 1/16 a fine enough resolution for
> > a wide selection of use cases?
>
> I don't know about any 'human interfaces' (faders, knob
> > If the user sends a 20khz sine wave into an application's
> > "volume" port that's either their mistake, or its exactly
> > what they wanted to do.
>
> If that is what they want to do they should use the right
> tool, wich would be ring modulator in a synth. I'd expect
> synths to use audio r
On Fri, Feb 19, 2010 at 09:38:45PM +, Simon Jenkins wrote:
> In my world it stands for "come on, give me a break man!"
>
> If it stands for anything harsher in yours then you have my sincere apologies.
>
> Really.
TNX :-)
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
__
On 19 Feb 2010, at 21:03, f...@kokkinizita.net wrote:
> On Fri, Feb 19, 2010 at 09:01:25PM +, Simon Jenkins wrote:
>
>> PS: FFS
>
> FFS ? Care to explain this acronym ?
>
> Ciao,
>
In my world it stands for "come on, give me a break man!"
If it stands for anything harsher in yours then
On Sat, Feb 20, 2010 at 12:03 AM, wrote:
> On Fri, Feb 19, 2010 at 09:01:25PM +, Simon Jenkins wrote:
>
>> PS: FFS
>
> FFS ? Care to explain this acronym ?
>
> Ciao,
>
> --
> FA
>
> O tu, che porte, correndo si ?
> E guerra e morte !
> ___
> Linux-a
On Fri, Feb 19, 2010 at 09:01:25PM +, Simon Jenkins wrote:
> PS: FFS
FFS ? Care to explain this acronym ?
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://
On 19 Feb 2010, at 20:55, f...@kokkinizita.net wrote:
> On Fri, Feb 19, 2010 at 07:43:58PM +, Simon Jenkins wrote:
>
>> This discussion is *about* using CV as automation data though.
>
> Is it ?
Yes.
>
>> Does CV turn into automation data when you downsample it?
>
> Do apples turn into
On Fri, Feb 19, 2010 at 07:43:58PM +, Simon Jenkins wrote:
> This discussion is *about* using CV as automation data though.
Is it ?
> Does CV turn into automation data when you downsample it?
Do apples turn into oranges when you cook them ?
Ciao,
--
FA
O tu, che porte, correndo si ?
E
On 19 Feb 2010, at 18:37, Jörn Nettingsmeier wrote:
> On 02/19/2010 05:40 PM, Paul Davis wrote:
>> On Fri, Feb 19, 2010 at 11:30 AM, Simon Jenkins
>> wrote:
>>> I'm reading "CV input" as "invitation to modulate" and, yes,
>>> sometimes it makes no sense to modulate at the full audio rate, but
>
On 02/19/2010 05:40 PM, Paul Davis wrote:
> On Fri, Feb 19, 2010 at 11:30 AM, Simon Jenkins
> wrote:
>> I'm reading "CV input" as "invitation to modulate" and, yes,
>> sometimes it makes no sense to modulate at the full audio rate, but
>> sometimes it does. I'm just not sure a special and predete
On Fri, Feb 19, 2010 at 12:39:35PM -0500, Paul Davis wrote:
> that all makes sense, but if you had a single floating point event per
> process cycle, you'd accomplish the same thing, and it would work no
> matter what the process cycle size was,
Assuming that control changes can be synchronised t
On Fri, Feb 19, 2010 at 12:30 PM, wrote:
> On Fri, Feb 19, 2010 at 11:40:51AM -0500, Paul Davis wrote:
>
>> my feeling precisely. the storage issue is an interesting one, but not
>> clearly an imperative. i do think that a general purpose event data
>> type would be useful.
>
> 1/16 (3 kHz) is ac
On Fri, Feb 19, 2010 at 11:40:51AM -0500, Paul Davis wrote:
> my feeling precisely. the storage issue is an interesting one, but not
> clearly an imperative. i do think that a general purpose event data
> type would be useful.
1/16 (3 kHz) is actually overkill for normal audio control.
Digital m
On Fri, Feb 19, 2010 at 11:30 AM, Simon Jenkins
wrote:
> I'm reading "CV input" as "invitation to modulate" and, yes, sometimes it
> makes no sense to modulate at the full audio rate, but sometimes it does. I'm
> just not sure a special and predetermined 1/16th or whatever control rate is
> wor
On 19 Feb 2010, at 15:29, Fons Adriaensen wrote:
> On Fri, Feb 19, 2010 at 02:55:51PM +, Simon Jenkins wrote:
>
>> If the user sends a 20khz sine wave into an application's
>> "volume" port that's either their mistake, or its exactly
>> what they wanted to do.
>
> If that is what they want
On Fri, Feb 19, 2010 at 02:55:51PM +, Simon Jenkins wrote:
> If the user sends a 20khz sine wave into an application's
> "volume" port that's either their mistake, or its exactly
> what they wanted to do.
If that is what they want to do they should use the right
tool, wich would be ring modul
On 19 Feb 2010, at 14:30, Fons Adriaensen wrote:
> On Fri, Feb 19, 2010 at 01:59:34PM +, Simon Jenkins wrote:
>> On 18 Feb 2010, at 17:32, alex stone wrote:
>>
>>> So it's feasible to create another type of port, (CV/Fs), without
>>> crippling something else in jack, or damaging the current
On Fri, Feb 19, 2010 at 02:15:13PM +, Simon Jenkins wrote:
>
> On 19 Feb 2010, at 13:47, Fons Adriaensen wrote:
>
> > On Fri, Feb 19, 2010 at 04:20:19PM +0300, alex stone wrote:
> >
> >> The use case i'm thinking of is a crescendo or decrescendo using gain
> >> in a continuous stream of data
On Fri, Feb 19, 2010 at 01:59:34PM +, Simon Jenkins wrote:
> On 18 Feb 2010, at 17:32, alex stone wrote:
>
> > So it's feasible to create another type of port, (CV/Fs), without
> > crippling something else in jack, or damaging the current API?
> >
> > If so, surely that would enhance further
On 19 Feb 2010, at 13:47, Fons Adriaensen wrote:
> On Fri, Feb 19, 2010 at 04:20:19PM +0300, alex stone wrote:
>
>> The use case i'm thinking of is a crescendo or decrescendo using gain
>> in a continuous stream of data. Will 1/16 reduce the..
>> "smoothness"?
>
> No, the DSP code has to pe
On 18 Feb 2010, at 17:32, alex stone wrote:
> So it's feasible to create another type of port, (CV/Fs), without
> crippling something else in jack, or damaging the current API?
>
> If so, surely that would enhance further Jack's capabilities, and open
> it up to more options for devs and users a
On Fri, Feb 19, 2010 at 04:20:19PM +0300, alex stone wrote:
> The use case i'm thinking of is a crescendo or decrescendo using gain
> in a continuous stream of data. Will 1/16 reduce the..
> "smoothness"?
No, the DSP code has to perform smoothing anyway, no matter
what the source of the contr
On Fri, Feb 19, 2010 at 04:05:02PM +0300, alex stone wrote:
> An obvious question i guess, but is 1/16 a fine enough resolution for
> a wide selection of use cases?
I don't know about any 'human interfaces' (faders, knobs,
mouses, touchscreens, acceleration sensors, whatever) that
can generate 10
I'd also add here that the CV suggestion isn't a replacement for midi,
but a new, separate, port data type. So those who are happy with using
midi can continue to do so.
Alex.
--
www.openoctave.org
midi-subscr...@openoctave.org
development-subscr...@openoctave.org
__
On Fri, Feb 19, 2010 at 4:05 PM, alex stone wrote:
> On Fri, Feb 19, 2010 at 3:48 PM, Fons Adriaensen wrote:
>> On Fri, Feb 19, 2010 at 03:51:22AM +0100, torbenh wrote:
>>
>>> On Thu, Feb 18, 2010 at 06:09:42PM +0100, f...@kokkinizita.net wrote:
>>>
>>> > We may not be talking of the same thing.
On Fri, Feb 19, 2010 at 3:48 PM, Fons Adriaensen wrote:
> On Fri, Feb 19, 2010 at 03:51:22AM +0100, torbenh wrote:
>
>> On Thu, Feb 18, 2010 at 06:09:42PM +0100, f...@kokkinizita.net wrote:
>>
>> > We may not be talking of the same thing. This is not about
>> > 'generic events' but about reduced-b
On Fri, Feb 19, 2010 at 03:51:22AM +0100, torbenh wrote:
> On Thu, Feb 18, 2010 at 06:09:42PM +0100, f...@kokkinizita.net wrote:
>
> > We may not be talking of the same thing. This is not about
> > 'generic events' but about reduced-bandwidth continuous
> > signals, represented as floating point s
On Thu, Feb 18, 2010 at 06:09:42PM +0100, f...@kokkinizita.net wrote:
> On Thu, Feb 18, 2010 at 11:43:07AM -0500, Paul Davis wrote:
>
> > On Thu, Feb 18, 2010 at 11:32 AM, wrote:
> >
> > > A reduced sample rate means less bandwidth. It doesn't mean
> > > that controls can't be 'sample accurate'.
On Thu, Feb 18, 2010 at 6:38 PM, Paul Davis wrote:
> On Thu, Feb 18, 2010 at 12:32 PM, alex stone wrote:
>> So it's feasible to create another type of port, (CV/Fs), without
>> crippling something else in jack, or damaging the current API?
>>
>> If so, surely that would enhance further Jack's ca
On Thu, Feb 18, 2010 at 12:32 PM, alex stone wrote:
> So it's feasible to create another type of port, (CV/Fs), without
> crippling something else in jack, or damaging the current API?
>
> If so, surely that would enhance further Jack's capabilities, and open
> it up to more options for devs and
So it's feasible to create another type of port, (CV/Fs), without
crippling something else in jack, or damaging the current API?
If so, surely that would enhance further Jack's capabilities, and open
it up to more options for devs and users alike. Even outside my
current setup, and as a user, i
On Thu, Feb 18, 2010 at 11:43:07AM -0500, Paul Davis wrote:
> On Thu, Feb 18, 2010 at 11:32 AM, wrote:
>
> > A reduced sample rate means less bandwidth. It doesn't mean
> > that controls can't be 'sample accurate'. You could even
> > extract 'sub-sample-accurate' discrete events from them,
> > i
On Thu, Feb 18, 2010 at 11:32 AM, wrote:
> On Thu, Feb 18, 2010 at 11:30:42AM +0100, Julien 'Lta' BALLET wrote:
>> I think a new type of 'audio'
>> port having only a sample per period could be a simple and handy
>> solution to this (one of the problem may be when you connect more than
>> one cv
On Thu, Feb 18, 2010 at 11:30:42AM +0100, Julien 'Lta' BALLET wrote:
> But actually, implementing it perfectly it jack apps may cost a lot if
> your control rate is the same as the audio rate (for example computing
> a filter coefs 96000 times per second).
You don't *have* to do it that way. As a
> > But actually, implementing it perfectly it jack apps may cost a lot if
> > your control rate is the same as the audio rate (for example computing
> > a filter coefs 96000 times per second). I think a new type of 'audio'
> > port having only a sample per period could be a simple and handy
> > s
2010/2/18 Jörn Nettingsmeier :
> On 02/18/2010 12:18 PM, alex stone wrote:
>> I will clarify here that i'm talking about a user experience, before
>> the discussion gets into jousting with white papers.
>
> that's what i was interested in, too. can you describe the advantages of
> the non-mixer
On Thu, Feb 18, 2010 at 2:34 PM, torbenh wrote:
> On Thu, Feb 18, 2010 at 02:18:54PM +0300, alex stone wrote:
>> I will clarify here that i'm talking about a user experience, before
>> the discussion gets into jousting with white papers.
>
> ok. so you basically say that midi channels are anno
On 02/18/2010 12:18 PM, alex stone wrote:
> I will clarify here that i'm talking about a user experience, before
> the discussion gets into jousting with white papers.
that's what i was interested in, too. can you describe the advantages of
the non-mixer approach (which i haven't tried yet) to
On Thu, Feb 18, 2010 at 02:18:54PM +0300, alex stone wrote:
> I will clarify here that i'm talking about a user experience, before
> the discussion gets into jousting with white papers.
ok. so you basically say that midi channels are annoying ?
how about several CC controllers flowing through
On Thu, Feb 18, 2010 at 02:18:54PM +0300, alex stone wrote:
> I will clarify here that i'm talking about a user experience, before
> the discussion gets into jousting with white papers.
>
> :)
hmm... i guess this was some thread hijack.
anyways. my papers are generally brown, because i spille
I will clarify here that i'm talking about a user experience, before
the discussion gets into jousting with white papers.
:)
Alex.
--
www.openoctave.org
midi-subscr...@openoctave.org
development-subscr...@openoctave.org
___
Linux-audio-dev mai
On Thu, Feb 18, 2010 at 11:30:42AM +0100, Julien 'Lta' BALLET wrote:
> Hello,
>
> That's true, this isn't new at all. but it has been lost for some
> times in the audio world in favor of midi, mainly afaik because too
> much cables just drives people crazy :)
>
> But actually, implementing it per
2010/2/18 Julien 'Lta' BALLET :
> Hello,
>
> That's true, this isn't new at all. but it has been lost for some
> times in the audio world in favor of midi, mainly afaik because too
> much cables just drives people crazy :)
>
> But actually, implementing it perfectly it jack apps may cost a lot if
>
2010/2/18 Jörn Nettingsmeier :
> On 02/18/2010 10:54 AM, alex stone wrote:
>> As a power user who's modestly (just kidding) keen on saving time,
>> using great workflow, and avoiding as much of the drudgery of editing
>> work over and over again to get an end result as is possible, i've had
>> the
Hello,
That's true, this isn't new at all. but it has been lost for some
times in the audio world in favor of midi, mainly afaik because too
much cables just drives people crazy :)
But actually, implementing it perfectly it jack apps may cost a lot if
your control rate is the same as the audio ra
On 02/18/2010 10:54 AM, alex stone wrote:
> As a power user who's modestly (just kidding) keen on saving time,
> using great workflow, and avoiding as much of the drudgery of editing
> work over and over again to get an end result as is possible, i've had
> the privilege and pleasure of testing and
As a power user who's modestly (just kidding) keen on saving time,
using great workflow, and avoiding as much of the drudgery of editing
work over and over again to get an end result as is possible, i've had
the privilege and pleasure of testing and working with a data protocol
called CV, or contro
51 matches
Mail list logo
