This is an exceptional announcement.
You may ask why announce a FVWM-Crystal release on the LAA,
fvwm-crystal being a desktop. That's simple, fvwm-crystal was improved
in 3.3.0 with a key modifier editor which let you change its key
modifiers.
This will affect only the extensive set of fvwm-cryst
On Fri, Feb 21, 2014 at 3:45 PM, Lieven Moors wrote:
> On Fri, Feb 21, 2014 at 03:29:40PM -0500, Paul Davis wrote:
> > On Fri, Feb 21, 2014 at 3:27 PM, Lieven Moors
> wrote:
> >
> > > Aren't most clients checking for
> > > the sample rate in the process callback anyway?
> >
> >
> > if they are,
On Fri, Feb 21, 2014 at 03:29:40PM -0500, Paul Davis wrote:
> On Fri, Feb 21, 2014 at 3:27 PM, Lieven Moors wrote:
>
> > Aren't most clients checking for
> > the sample rate in the process callback anyway?
>
>
> if they are, then they are doing it wrong.
That would be me ;-)
I probably did t
On Fri, Feb 21, 2014 at 08:34:16PM +0100, Jörn Nettingsmeier wrote:
> On 02/21/2014 07:52 PM, Lieven Moors wrote:
> >>it was part of the API very early on, then we decided we didn't want to
> >>impose the possibility of change on clients. as time goes on, it becomes
> >>clear (to me at least) that
On Fri, Feb 21, 2014 at 08:34:16PM +0100, Jörn Nettingsmeier wrote:
> having wired up a complex signal graph, which for the most part
> depends on the studio, not on the project at hand, and then having
> to deal with different projects in different sample rates.
> ...
> as it is now, i
On 02/21/2014 07:52 PM, Lieven Moors wrote:
it was part of the API very early on, then we decided we didn't want to
impose the possibility of change on clients. as time goes on, it becomes
clear (to me at least) that we should have implemented it.
What would be use cases for changing the sample
> it was part of the API very early on, then we decided we didn't want to
> impose the possibility of change on clients. as time goes on, it becomes
> clear (to me at least) that we should have implemented it.
What would be use cases for changing the sample rate dynamically?
lieven
_
2014-02-21 17:21 GMT+02:00 Paul Davis :
>
>
>
> On Fri, Feb 21, 2014 at 10:04 AM, Stefano D'Angelo
> wrote:
>>
>>
>>
>> Well, here
>> http://jackaudio.org/files/docs/html/group__ClientCallbacks.html
>> I only see that process has to be RT-safe and thread-init needs not,
>> but regarding others I h
On Fri, Feb 21, 2014 at 10:04 AM, Stefano D'Angelo wrote:
>
>
> Well, here
> http://jackaudio.org/files/docs/html/group__ClientCallbacks.html
> I only see that process has to be RT-safe and thread-init needs not,
> but regarding others I have no clue. Is that stated somewhere else or
> am I missin
2014-02-21 16:51 GMT+02:00 Paul Davis :
>
>
>
> On Fri, Feb 21, 2014 at 9:38 AM, Stefano D'Angelo
> wrote:
>>
>> Sorry guys, other two (silly?) questions:
>>
>> 1. apart from the process callback, which callbacks need to be
>> RT-safe? Looking around I found a master thesis [1] that says: "Apart
>
On Fri, Feb 21, 2014 at 9:38 AM, Stefano D'Angelo wrote:
> Sorry guys, other two (silly?) questions:
>
> 1. apart from the process callback, which callbacks need to be
> RT-safe? Looking around I found a master thesis [1] that says: "Apart
> from
> the JackProcessCallback callback, which is called
Sorry guys, other two (silly?) questions:
1. apart from the process callback, which callbacks need to be
RT-safe? Looking around I found a master thesis [1] that says: "Apart
from
the JackProcessCallback callback, which is called in the realtime
audio thread for obvious reasons, all other callback
Hi,
For those of you who are interested real world results for ffmpeg with
opencl we have run some benchmarking tests across our cluster. At the end
of last year there was a flurry of activity integrating opencl with
ffmpeg. The work was undertaken by multicorewareinc who is also the
official keep
13 matches
Mail list logo
