Hi Nasca,
yesterday I tried your first version of ZynAddSubFX on my PC at home,
and though I was not able to use it successfully yet, I'd like to give
some feedback -
First, some info: My system is running Debian, with recent ALSA
(0.9.0rc3), recent FLTK (1.1.0rc1) and kernel 2.4.17. FFTW is 2.1.3.
Compiling ZynAddSubFX, I found that it tries to include "drfftw.h" in
DSP/FFTwrapper.h. I don't have this file, but reading into the FFTW
source and looking at my Debian packages, I saw there are version for
single precision and double precision, and though the FFTW source
package recommends to call the include files for the double precision
version "drfftw.h", it is actually only named "rfftw.h". Ok, so I
changed that and compilation went on a lot further.
Later on, another compiler error:
make[1]: Entering directory `/u1/src/zyn/ZynAddSubFX-1.0.0/src/Synth'
gcc -O6 -c -o ADnote.o ADnote.C
gcc -O6 -c -o Envelope.o Envelope.C
gcc -O6 -c -o LFO.o LFO.C
gcc -O6 -c -o OscilGen.o OscilGen.C
In file included from OscilGen.C:29:
../DSP/FFTwrapper.C: In function `void FFTsmps2freqs(int, float *, float
*)':
../DSP/FFTwrapper.C:31: passing `float *' as argument 2 of
`rfftw_one(fftw_plan_struct *, fftw_real *, fftw_real *)'
../DSP/FFTwrapper.C: In function `void FFTfreqs2smps(int, float *, float
*)':
../DSP/FFTwrapper.C:40: passing `float *' as argument 2 of
`rfftw_one(fftw_plan_struct *, fftw_real *, fftw_real *)'
make[1]: *** [OscilGen.o] Error 1
make[1]: Leaving directory `/u1/src/zyn/ZynAddSubFX-1.0.0/src/Synth'
make: *** [all] Error 2
Looking at DSP/FFTwrapper.C, I see you are using the type "REALTYPE *"
(with REALTYPE being defined in global.h as being float) for both
"freqs" and "smps". I changed that to the correct prototype, fftw_real
*, and now everything compiles and links.
However, when I runs the binary, as soon as I connect its ALSA port to
e.g. vkeybd and try to play it, it gives a segfault. I compile it with
-g -O to see where this happens, but the gdb output is rather useless
for me, probably due to the crash happening in another thread:
#0 0x40301730 in free () from /lib/libc.so.6
(gdb) bt
#0 0x40301730 in free () from /lib/libc.so.6
#1 0x403016d3 in free () from /lib/libc.so.6
#2 0x4011deec in fftw_free () from /usr/lib/libfftw.so.2
#3 0x00000010 in ?? ()
Error accessing memory address 0x6: No such process.
I hope this is not due to my "fix".
A similar crash happens whenever I try to load a master file:
(gdb) bt
#0 0x40301730 in free () from /lib/libc.so.6
#1 0x403016d3 in free () from /lib/libc.so.6
#2 0x4011deec in fftw_free () from /usr/lib/libfftw.so.2
#3 0x400ea6ac in rfftw_one () from /usr/lib/librfftw.so.2
#4 0x0805be93 in OscilGen::saveloadbuf ()
#5 0x08053adb in ADnoteParameters::saveloadbufvoice ()
#6 0x08054860 in ADnoteParameters::saveloadbuf ()
#7 0x080520a2 in Part::saveloadbuf ()
#8 0x080500a0 in Master::saveloadbuf ()
#9 0x080752d2 in MasterUI::cb_Open ()
#10 0x4016ad9a in Fl_Menu_::picked () from /usr/lib/libfltk.so.1.1
#11 0x4016b414 in Fl_Menu_Bar::handle () from /usr/lib/libfltk.so.1.1
#12 0x4015b22d in Fl_Group::find () from /usr/lib/libfltk.so.1.1
#13 0x4015b7cc in Fl_Group::handle () from /usr/lib/libfltk.so.1.1
#14 0x401483b2 in Fl_Window::handle () from /usr/lib/libfltk.so.1.1
#15 0x40147d09 in fl_throw_focus () from /usr/lib/libfltk.so.1.1
#16 0x40147e58 in Fl::handle () from /usr/lib/libfltk.so.1.1
#17 0x40186781 in fl_handle () from /usr/lib/libfltk.so.1.1
#18 0x401850aa in Fl::remove_fd () from /usr/lib/libfltk.so.1.1
#19 0x40185420 in fl_ready () from /usr/lib/libfltk.so.1.1
#20 0x40185321 in fl_wait () from /usr/lib/libfltk.so.1.1
#21 0x401475c9 in Fl::wait () from /usr/lib/libfltk.so.1.1
#22 0x40147657 in Fl::wait () from /usr/lib/libfltk.so.1.1
#23 0x080795f5 in thread3 ()
#24 0x403b3fa5 in pthread_start_thread () from /lib/libpthread.so.0
Oh, and I noticed the default filter mask in the file requester is wrong
- I always need to change this from (*.mas_zyn) to * to see the master
files.
Any hints or suggestions are welcome. The demo files sound very
interesting, so I am eager to get this to run.
Thanks,
Frank
Hi, I wrote a software syntesizer for Linux, it is
available at http://zynaddsubfx.sourceforge.net/ or
http://sourceforge.net/projects/zynaddsubfx/ . It has
many features including: polipohony, multi-timbral,
microtonal capabilities, 2 synth engines, effects
(system and insertion), user interface.
I started this project on March 2002 and this is the
first relase. I hope that you'll like it.
Paul.
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
Hi,
I'm reading through the Alsa HOWTO and wondering if there are any buffer
setting or other options for setting internal buffer sizes in Alsa? I
normally set these things myself in jack, but in this case cannot.
One individual that I'm working with is getting excessive xruns on a
laptop. His BIOS does not seem to allow IRQs be set for any internal device.
His sound chip is on IRQ5, which is about as bad as it's going to get.
He is attempting to play a DVD to his screen and sound device, but is
getting excessive xruns. We're just searching around for ideas on how to
approach the problem.
If there are no module load options, might this be approached by setting
some buffer size in alsa itself and recompiling?
Anyway, thanks!
Mark
Hi everyone,
Just released the latest revision of the IETF Internet-Draft
to standardize the RTP packetization for MIDI. The document reflects
the comments submitted on the last document revision by several
LAD-folks (see the document change log for details ...).
While this draft isn't the "Last Call" document, we're
probably only a few revisions away from Last Call, so if anyone has
been holding off on the reviewing the memo and sending comments, now
is a good time to do so ... below is the abstract and document
download info:
---
>From: Internet-Drafts(a)ietf.org
Subject: I-D ACTION:draft-ietf-avt-mwpp-midi-rtp-05.txt
Date: Tue, 24 Sep 2002 07:52:50 -0400
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Audio/Video Transport
Working Group of the IETF.
Title : The MIDI Wire Protocol Packetization (MWPP)
Author(s) : J. Lazzaro, J. Wawrzynek
Filename : draft-ietf-avt-mwpp-midi-rtp-05.txt
Pages : 94
Date : 2002-9-23
The MIDI Wire Protocol Packetization (MWPP) is a general-purpose
RTP packetization for the MIDI command language. MWPP is suitable
for use in both interactive applications (such as the remote
operation of musical instruments) and content-delivery applications
(such as MIDI file streaming). MWPP is suitable for use over
unicast and multicast UDP, and defines tools that support the
graceful recovery from packet loss. MWPP may also be used over
reliable transport such as TCP. The SDP parameters defined for MWPP
support the customization of stream behavior (including the MIDI
rendering method) during session setup. MWPP is compatible with the
MPEG-4 generic RTP payload format, to support the MPEG 4 Audio
object types for General MIDI, DLS2, and Structured Audio.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-mwpp-midi-rtp-05.txt
---
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
> david(a)gardena.net writes:
> you can't ask units about things,
> unless you have two cables - and that's not really part of the
> standard
Actually, it is. The System-Exclusive Universal ID command
space is general-purpose functionality that, in many cases,
assumes units talking to each other via cable pairs. See:
http://crystal.apana.org.au/~ghansper/midi_introduction/midi_sysex_universa…
for details. The simplest example is the Generic Handshaking
instructions, which do flow-control for big Sample Dumps via
a set of commands implementing ACK, NAK, WAIT, EOF, etc.
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
So who is orm, and are they available for comment?
So I think I have things narrowed down a little. It seems that he
cardbus/Digiface combo is stuck at a sample rate of 32k, even though the
/proc file states that it is at 48k. This dose not happen using the pci
interface.
The Control, Status, and Status2 registers seem correct. So I am lost on
where to go next. Any suggestions?
On Fri, 2002-07-05 at 17:03, Paul Davis wrote:
> >Just unwrapped my new thinkpad, so I am thinking of ordering the cardbus
> >interface for my hdsp. Has anyone gotten the cardbus to work with the
> >digiface box?
>
> it works (orm has reported it working). it seems very dependent on the
> kernel, cardbus utilities and possibly the underlying hardware. if
> these 2 succeed with their task of making the pcmcia card appear like
> a normal PCI device, then everything proceeds as normal. several
> people have combinations of these 3 that fail at this goal.
--
drh(a)niptron.com
Great spirits have always encountered violent opposition from mediocre
minds.
-- Albert Einstein
They laughed at Einstein. They laughed at the Wright Brothers. But
they
also laughed at Bozo the Clown.
-- Carl Sagan
Hi,
I haven't looked at the latest versions of Fruity for a while but started
working on something that is quite similiar to your description in the
beginning of this year. I have now reached a certain level where the core
signaling engine becomes usable.
I don't know if you have ever worked with buzz but I consider some sort of UI
quite similiar to its.
How does this sound to you?
mm
On Wednesday 04 September 2002 8:08 am, Tim Hockin wrote:
> I know someone on here once posted about doing a FruityLoops work-alike
> app. Are you still around?
>
> I have been tossing about this idea for a free, high quality,
> well-architected, virtual studio for a while. If I had a collaborator or
> two, I'd probably be more inclined to do it.
>
> Anyone? My thoughts so far:
> * a plugin API like LADSPA but less 'S'
> * a modular-synth core engine
> * layered control - modular synth, or a Fruity-like interface on top
> * written in C
> * clean code, modular, extensible, blah blah...
>
> There is a ton of code waiting to be borrowed. Whole portions may not need
> to be written. I haven't investigated THAT far yet.
>
> Tim
We are using LynxOne soundcard with OSS driver in digital mode with external clock option.
We want to check the presense of Digital clock, before starting the audio process.
Initially, we thought of using the input H/W buffer sample count to check that. But it does not work always. Sometime even with valid external clock, driver won't place any data in the hardware buffer even after few minutes.
Did you come across this problem?
Also we have to delay the Timecode. We are not using MIDI feature. But time code comes only in MIDI port. Is it easy to change the timecode (LTC) in the MIDI stream?
-----Original Message-----
From: Paul Davis [mailto:pbd@op.net]
Sent: Thursday, September 19, 2002 7:16 AM
To: linux-audio-dev(a)music.columbia.edu
Subject: Re: [linux-audio-dev] Basic information
>>> Hi. Could anyone point me to some very basic information to give me
>>> some
>>> idea of programming for sound in linux.
>>
>> we can't even begin to answer such a nebulous question i'm afraid.
>
>why not? I would just start to have a look at other sound applications
>and
>try to understand what they do. That's actually how I did it. And then
>you
>can get yourself a working installation of alsa and try to build the
>existing documentation. In the meantime there's even a small primer,
>how to open a sound device and make some noise.
because its far from clear that this is the right thing to do with an
SC port. if you don't know what SC is, you might not realize that the
way 95% of all linux audio applications are written doesn't fit with
SC's basic architectural model at all. many people think that writing
a soundapp consists of opening a device, dumping some data to it and
closing it. some programs can do that, but SC cannot.
i don't know how much the questioner knows about the internal design
of SC. its therefore not possible to answer the question until he pins
down what he wants to do.
--p
_______________________________________________
linux-audio-dev mailing list
linux-audio-dev(a)music.columbia.edu
http://music.columbia.edu/mailman/listinfo/linux-audio-dev
Hi. Thanks to everyone for the advice. I've been poking around
in a number of sources (including the Supercollider code), and
it appears that I need to spend a bit more time on various
learning curves. My immediate aim is to install WindowMaker
and GNUStep on my linux box (tried to do so on a solaris box
but encountered 'difficulties' :-(), and write a few simple gui
applications in objective-c. After that, I can have another
look at the task at hand. SC does use core-audio, and I've
noted the advice to use JACK.
Hopefully I'll resurface on this problem in a while!
Cheers,
Ross-c
