Am I right in thinking you could redirect SpiralSynth's output to one of
your PCM outputs (/dev/snd/PCM???) in the rc file?
(I don't know much about ALSA yet)
You *might* be able to redirect the output to stdout and pick it up with
ecasound, to output it properly,
SpiralSynth | ecasound -i:stdin -o alsa,0,0
Just some ideas,
Dave
Be sure to try out Paul's crazy python sequencer if you get it working!
"Brian Parish (EPA)" wrote:
>
>
> 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
