> If 50 persons say "Please would you be so kind ..."
> And another 50 say FY, in the end it's the number that counts. 100
> (potential) customers. Each one of use is responsioble for his *own*
> statements.
Sorry, maybe we're from different planets, but i can't follow. Your attitude
is disgusting
> IMO the issue is not whether RME's concern is valid - clearly it is.
> Sorry, but arguing otherwise makes us look stupid and naive. The issue
> is how to address this concern. If that means a closed source Linux
> driver, fine.
I'm also happy to hear this. I've had quite some debates on the RM
Hi,
there's no release as such but apparently Roger Dannenberg kindly passes the
source to whoever is interested. The platform features really interesting
concepts but doesn't seem to be ready-for-use.
greetingsm
Thomas
> guenter geiger wrote:
> > You might take a look at Aura/Serpent from Roger
Hi all,
can anyone give me pointers on how the overview cache for a zoomable
waveform display is organized?
One can see accurate and fast displays in a lot of applications but i guess
the rendering of this is not straightforward.
best greetings,
Thomas
> > How do you handle lifting, moving, and setting down the needle? Could
we
> > get needle-up and needle-down events?
>
> The final scratch plates have time info encoded in the signal. Not that
> I know much about it, but I'd imagine that was, in fact, the only thing
> encoded in the signal
> However, it's more difficult to express composition algorithms
> using constraint based or artificial intelligence techniques.
> That's were a high-level language comes in handy.
>
> Maybe a "python" external object for PD/jMax would be nice?
Hi, it's in the works. (and a simple version with on
> There are various products (Reaktor, Nord Modular, MAX/MSP) that would be
> suited to this task, but I would like to understand what is happening at a
> very low level and have that inform my creative process.
>
> Is anyone on this list doing this sort of thing? I would love to
> hear from
> yo
