Title: RE: Hello LinArt!

Hi David,

I tried out SpiralSynth, but it shares the problem I've found with almost every
linux app available - doesn't understand how to use the multi-channel API in
ALSA.  ecasound is about the only thing I've found so far that does, although I
believe that snd can also do it if built with the right options.

The result is that SpiralSynth fails at startup because the sound card would not
accept your initialisation.  It exits gracefully with an appropriate error message,
so congratulations on that!

I believe that ALSA 0.6.x will support these multi-channel cards (mine is a Midiman
Delta 66)in a more transparent manner, so maybe just waiting for that release will
provide a solution.  Please let the linart list know if you implement multi-channel
API support in the meantime though, because your synth looks really nice, and I'd
love to give it a try.

I guess that one other way around the problem in the meantime would be to allow
SpiralSynth to come up without a sound card in "render to wav file only" mode.  At
least then those with incompatible cards like me could try it out using ecasound or
similar to play the wav files.  OK, it's clumsy, but it's also probably easy to
implement.  (easy for me to say ;-)

best regards
Brian

-----Original Message-----
From: Paul Winkler [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 22, 2000 4:25 AM
To: [EMAIL PROTECTED]
Subject: Re: Hello LinArt!


David Griffiths wrote:
> Paul Winkler wrote:
> > monosynths are great fun too (I have an SH-09!).
>
> That's quite ironic, I started making SpiralSynth to stop myself from buying
> one of them. I also borrowed a friend's Moog Rogue for a few weeks, while I
> was designing SpiralSynth, I was hoping some of the magic might rub off!
> They are such nice things to play with, even when your not really thinking
> about what your doing you can come up with some really nice sounds. They are
> just too damn expensive :(

Yep, it helps to find a friend who never plays anymore who has old
gear lying around. :) Now if only I could talk my dad out of his
juno-60...
 
> > 1) Raw MIDI input from any user-selected device including named
> > pipes or STDIN.
>
> The file it reads midi from is specified in the .Spiralrc file (I don't know
> if that helps)

I actually tried it before I wrote, but I just tried again and this
time I did it right!

To get input from stdin, put this in .Spiralrc:
Midi              = /dev/fd/0

I have a little test program that spits out midi bytes to stdout; I
can now use this like so:

        ./p1.py | ./SpiralSynth-i386Linux-0.1.4

Or to use a named pipe instead of stdin:
put this in .Spiralrc:
Midi = ./Foo
 
Then do this:

        mkfifo Foo
        ./p1.py > Foo&
        ./SpiralSynth-i386Linux-0.1.4

Very cool! This is a great way to create Spiral sounds because you
don't have to play the keyboard while you tweak.

Here's the test script:

#!/usr/bin/python
#
# spew a random pattern in midi :)
# Copyright (c) 1999 Eric S. Tiedemann
# Released under the GPL (version 2 or later; see file COPYING)

### comments added by Paul Winkler

import struct
import time
import sys

def non(k, v):
    ### 4-byte midi message. k="key", v="velocity"
    ### Stuff that into 3 bytes and write to stdout.
    sys.stdout.write(struct.pack('BBB', 0x90, k, v))
    sys.stdout.flush()

def r(s): # delay between notes
    time.sleep(s)

def p1(k, s, h, o, t = 1):
    # k, s, h, and o are key values
    # for a 4-note pattern.
    # t is time scale for rests. larger = slow down.
    non(k, 80)
    r(1 * t)
    non(k, 60)
    r(1 * t)
    non(s, 60)
    r(1.5 * t)
    non(h, 60)
    r(1.5 * t)
    non(k, 60)
    r(1 * t)
    non(s, 60)
    r(1 * t)
    non(o, 40)
    r(1 * t)

    non(k, 60)
    r(.5 * t)
    non(h,60)
    r(.5 * t)
    non(h,60)
    r(.5 * t)
    non(k, 60)
    r(.5 * t)
    non(s, 60)
    r(.75 * t)
    non(h,40)
    r(.25 * t)
    non(k, 60)
    r(1 * t)
    non(o, 40)
    r(.5 * t)
    non(o, 40)
    r(.5 * t)
    non(k, 60)
    r(.5 * t)
    non(k, 60)
    r(.5 * t)
    non(s, 60)
    r(.5 * t)
    non(s, 60)
    r(1.5 * t)


while 1: # run forever.
     # Use nice key values for general-MIDI drumset.
     p1(68, 66, 61, 64, .2)
   
sys.stdout.close()

sys.exit(0)

# End of p1.py
       
> > 2) "Aux" input so Spiral's filters can be used to process other
> > audio data. This is fun with old hardware synths; why not
> > soft-synths too?
>
> I've been planning to allow samples to be played like extra waveforms from
> the oscillators at some point.

That would be cool. Even cooler if you can rig up full-duplex input
so you can process realtime input from the soundcard.

> > 3) Plugin support. See the lad page for links to LADSPA.
>
> At first glance, this looks a bit complicated, but it would be great.
> SpiralSynth could be either a plugin or a host I suppose.
> I'll look into that.
>
> Phew, I had been hoping to slow down development, and write some music - some
> hope :)

Oh, there's no hurry. Have fun!
One thing you definitely might want to do if you haven't already is
try to make it run nicely in realtime... check out Benno Sennoner's
HOWTO on this:
 http://www.crosswinds.net/~linuxmusic/lowlatency.html
( I haven't looked at your source, and I haven't even got a working
low-latency kernel at the moment so forgive me if you've done this
already.)

> Anybody out there know of any decent mutitracking software they can
> recommend? (Not neccisarally feature packed, but stable and easy to use)

I've tried:

Broadcast2000: crashes constantly especially when you try to use
effects.
Open source so presumably it's fixable. :)

Ecasound: cool does-everything tool. Doesn't crash but console
interface might not be what you mean by "easy". :)  There's a front
end called Ecawave that I haven't checked out yet. Not sure if
ecawave handles multitracks. (Ecasound does.)
http://www.wakkanet.fi/~kaiv/ecawave/

There's also another front-end that handles multitrack: see
http://socrates.berkeley.edu/~nklepeis/ECO/

Multitrack: buggy but basically useable. The author appears to have
dropped off the face of the earth shortly after saying he'd release
the source code. :(
So this is an orphaned project that might never get any better.
The binaries are old - I don't know how well they'll work with a 2.2
or 2.4-pre system.

SLab: Tons of features, overwhelming interface, buggy and unuseably
slow last time I tried it... but that was a long time ago on a P-133
with 32MB RAM. Things might be better now. It was 2.-something when
I tried it, now it's up to 4.0.

Also worth checking out: Ardour. I don't think it's anywhere near
"stable" yet, though.

All this can be found from Dave Phillips' page of course...


--
.................    paul winkler    ..................
slinkP arts:   music, sound, illustration, design, etc.
           web page:  http://www.slinkp.com
      A member of ARMS:   http://www.reacharms.com

Reply via email to