[chuck-users] Low-latency in Windows, Dynamic LInking and UI Idea
vtatila at mail.student.oulu.fi
Mon Mar 5 13:48:02 EST 2007
Spencer Salazar wrote:
>>>> 3. Is there any way to decrease the latency on WIndows platforms
>>>> for tru realtime MIDI playback and audio processing similar to
>> just read that ChucK is based on SDL and
>> meaning a 20 ms latency is quite an achievement in many cards.
>> would be great if the WIndows port of SDL had native ASIo support
> ChucK does use DirectSound on Windows, which indeed makes attaining
> realtime latency problematic.
Yeah, for all the hassle and worries about legacy sound APIs like OSS and
hardware mixing, this is about the first time I'm envious of Linux users for
their sound support, <smile>. That is to say ALSA does give low latency if
you have the drivers, although incidentally I've heard the TerraTec drivers
for LInux have some extra latency issues, oh well.
Quoting joerg here:
you could use asio4all
is supposed to be working with all soundcards
Yeah, that works fine for SoundMAX cards such as the one in this laptop. But
the problem is not the lack of low-latency ASIO but DirectSound itself. Does
anyone know how apps like Sonar can achieve low latency by using MS
technology? I've heard the names WDM and kernel streaming but neither says
much to me as I'm not a driver developer.
>> having constructor support would rock.
>> As well as the ability to declare abstract or interface classes
> Yes--real constructors are definitely on the todo list, and ChucK
> actually reserves the "interface" and "implements" keywords for
> potential future use.
Ah, nice. Speaking of future extensions, does this snippet in the ChucK
manual mean I can actually already load code on the fly much like using a
DLL or a shared library? That is:
ChucK Standard Libraries API these libraries are provide by default with
ChucK - new ones can
also be imported with ChucK dynamic linking (soon to be documented...).
I wonder when this will be, in fact, documented.
> OpenGL support (GLucK) is currently in development limbo, but its
> something we'd very much like to make available in the near future.
I see, which reminds me of another thing entirely. Will ChucK have some day
in the future a sufficiently powerful, cross-platform toolkit for
effortllessly building synth panels as in Reaktor? If it would also support
presets, MIDi learn, respect user color and font preferences and would be
keyboard and screen reader accessible, I'd be chucKed into virtual analog
heaven then, <grin>.
Here are some thoughts as to what might need to be implemented:.
Coarse value adjustements: knobs and sliders with a keybord interface
modelled on sliders.
Exact value adjustements: text entry boxes and spinners
Toggle buttons: much like small push buttons
Radio buttons: AKA switches in synth speak, again the kbd interface could be
lifted from a radio group
output: analog meters and read-only edit boxes AKA read-only displays
Not to mention groups for putting controls into. This is about the controls
early Reaktor's had and was quite sufficient for a long time. If the native
controls could be used, I wonder if WX WIdgets would be sufficiently
portable and powrful.
>From an accessibility point of view, I do wish controls would have a proper
auto-generated but overridable tab order, the concept of keyboard focus and
labels that are clearly defined for assistive technology (e.g. using native
accessibility APIs), as well as hotkeys for both moving to controls like
groups and interacting with them. But I'll stop here before this turns into
an accessibility rant, <smile. Truth be told, Reaktor had, it does not any
more, one of the most keybord-usable panels and most VST plugs are horrible
in that regard. Apparently most hosts don't even handle the keyboard
messages so the plugs could process them.
With kind regards Veli-Pekka Tätilä (vtatila at mail.student.oulu.fi)
Accessibility, game music, synthesizers and programming:
More information about the chuck-users