On Sat, Nov 02, 2002 at 08:12:10 +0100, Tim Goetze wrote:
> >In the instantaite block fixes it up more-or-less. Maybe even adds a bit
> >of compression (it boosts the gain to make it roughly 1:1 too).
>
> have you modified the lut in the meantime? i don't seem to be getting
> the right results with the log scaling you use.
Did you try adding the 0th harmionic to the front of the table, and
dropping the last harmonic? That made it sound pretty good for low notes.
> ah, i'm afraid that's only half the truth. try the link i posted
> to the list; somebody has been doing this before us and published.
> i still haven't checked for frequency dependency of valve distortion,
> but it seems they have, and found it to exist.
Figures, on both counts.
> additionally, it seems that to tackle intermodulation distortion it
> is best to split the incoming signal to multiple bands (those great
> theoreticians have been using FIRs in matlab) and shape each band
> separately. they do in fact use two blended shapers per band.
OK, why do they use two shapers? Or is it one cheby and one non polynomial?
> btw, the 'lower frequency' phenomenon occurs with the real amp, too,
> only it's not as pronounced.
OK, I didn't know that.
> drat. i fear that we'll need to cool this box into superconductance
> to get the effect done *really* right.
Yeah, I'm thinking we're not tackling it right, if behringer can knock out
a virtual amp harware box for E150 it can't the that cycle hungry.
- Steve
Hello.
I'm a blind Linux user since 1997, and I'm also
interested in doing music on Linux.
Since I'm the synth-type-of-guy, I'd really love
to be able to play with software based synths, a little
bit of step seuqencing, and some sample based stuff.
Controlling my SuperNova DrumMachine via MIDI (and being able
to sequence it) would also be nice.
Well, since blind people are still very GUIdisabled in Linux, the only things I can use are those which are either
CLI or curses based,
or expose their functionality through a easily programmable
API.
If only choice number two is available, that isn't that nice, because I'd like to
be productive sometimes, and if you have to write yourself
every little bit of convenience thing, you are not really making music, you're programming :).
THe biggest problem there is that you actually
dont do much realtime modifications. And realtime
changes to sequences or parameters of things are very important
for experimental type of electronic music.
SO I've looked around, and found some stuff, but
still have nothing really useful.
Here is the list of software which is nicely
done, and GUIless friendly:
Ecasound!!! Kai, cool done! But its not the thing I need
unfortunately.
GDAM. Looks promosing because the workhorse
code is nicely separatedd from the GUI, and I already
managed to program gdam123 a bit to allow rate control,
but again, its not really what I'm looking for although
it seems nice.
Ardour is also somewhat accessible from what I hear, but
again, its a multitrack recorder, not what I need.
SSM: I looked at the code, and it seemed quite
horrible to me. GUI and workhorse code are tightly coupled, I see
no way for me to get to the underlying functionality.
What I'm really missing is:
Some Sequencer which is capable of MIDI out and in
Some Synth software which is controllable through that
sequencer. SSM seems nice, but its a GUI-only thing,
PD is even more GUI...
Some LADSPA plugins seem promising, but again its too much
putting-things-together work.
Can anyone add anything to that list?
Can anyone help with the listed problems?
Is some software author (i.e., the SSM author) interested
to work with me on getting GUIless controllability?
I'm not a good C programmer, but I'm at least
familiar with what we'd need to work efficiently...
Or am I missing anything completely? Some trick
to circumvent the need for some GUIs? Can anyone
give an example on how to create a short trtack
with some samples and a synth line without X?
--
CYa,
Mario | Debian Developer <URL:http://debian.org/>
| Get my public key via finger mlang(a)db.debian.org
| 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
> i'm not up to understanding all implications of the fact that the
> incoming signal is not a pure sine;
This intrigued me -- I think the answer is that the
process is not linear -- you get sum and difference tones much as
in complex fm. I added an example to clm.html. Back when
Marc and I were first messing around with waveshaping,
I asked him about some way to set up the
poynomials to get a particular spectral evolution
as the amp increases (input amp being similar to
fm index in this context) -- you can use Chebychev polynomials of the
2nd kind to play single-sideband tricks, so it seemed
like there might be possibilities; other things intervened,
and I don't think Marc ever got around to dealing with it.
found out some interesting facts about the chebyshev. been playing
around a little with a chebyshev shaper, feeding it various harmonic
amplitudes and a sine oscillation, taking an FT afterward.
it seems that in order to get a harmonic of amplitude 0.5, you must
not pass 0.5 to chebpc for that harmonic, but sqrt(2)/2. for a
harmonic of amplitude .333333333, pass in sqrt(3)/3, etc. thus, if we
want amplitude 'a' for a given harmonic, the chebpc coefficient is 'a
* sqrt (1/a)' rather than simply 'a'. (negative amplitudes: ?).
the peak value of the chebyshev-shaped output will be the sum of all
coefficients calculated in this manner. the further the incoming sine
is scaled down (from [-1,+1]), the less the harmonic mix will match
the wanted amplitudes.
for the amp code, this would mean we should probably try the
following: compress/expand the incoming signal to fit exactly into
[-1, 1] (normalize). the coefficient tables need some treatment, too
-- we want the output sum to be 1, and the relative strengths of the
harmonics to match.
i'm not up to understanding all implications of the fact that the
incoming signal is not a pure sine; neither do i have a recipe for
preparing the coefficient tables -- if we scale the individual
coefficients by 1/sum their mix will not match what we want.
tim
We at the LinuxSampler project,
http://linuxsampler.sourceforge.net will go the GUIless route too
and as Juan L. suggested it is probably wise to use a TCP socket because it
allows remote controllability which can sometimes be very helpful.
Imagine these racks found in webfarms starting making music :-)
Anyway as our project advances, I hope that some good soul will implement
a CLI interface for the sampler too so that it becomes more accessibile for
people with disabilities.
I agree with your stance about merging GUI and engine code: it is a mess and
often introduces many maintenance and performance problems.
Most audio programmer so not seem to realize that using mutexes called from
GUI threads that share data with the audio thread speaks SUICIDE because you
will never be able to ensure that your sub-5 msec audio engine does not drop
out under heavy load. Yes ... (blocking) mutexes simplify a bit the
programmer's task , but I'm sorry to say it your product will never be usable
in the pro audio field.
Hoping for a peaceful, client-server centric audio application world.
:-)
Benno
--
http://linuxsampler.sourceforge.net
Building a professional grade software sampler for Linux.
Please help us designing and developing it.
Paul Davis wrote:
> it shouldn't be *too* difficult ...
Someone suggested LADSPA but I do not see an easy way to do it since LADSPA
does not support MIDI and this seems a VST2 instrument.
Time to intruduce an instrument API or extend LADSPA ?
Of course one can write a standalone JACK client (currently probably the best
thing to do), but this means reinventing the wheel all over again.
Let see what comes out of LinuxSampler, the discussions and ideas proposed on
the list are quite interesting perhaps it would not be a bad idea to add VST
instrument support so that opensource plugins like that one could be easily
ported without needing and extensive rewrite (at least for the DSP part, the
GUI stuff is a separate issue).
Does anyone remember if it is possibile to use the VST headers (unmodified)
on Linux or is Steinberg against ?
I remember that some time ago Paul Davis wrote about these issues on the
mailing lists but I do not remember what the outcome was.
Thoughts ?
Benno
--
http://linuxsampler.sourceforge.net
Building a professional grade software sampler for Linux.
Please help us designing and developing it.
On Tue, 05 Nov 2002 15:02:13 -0500
linux-audio-dev-request(a)music.columbia.edu wrote:
> linux-audio-dev -- confirmation of subscription -- request 999072
>
> We have received a request from 216.254.100.146 for subscription of
> your email address, <stuart(a)realhappy.net>, to the
> linux-audio-dev(a)music.columbia.edu mailing list. To confirm the
> request, please send a message to
> linux-audio-dev-request(a)music.columbia.edu, and either:
>
> - maintain the subject line as is (the reply's additional "Re:" is
> ok),
>
> - or include the following line - and only the following line - in the
> message body:
>
> confirm 999072
>
> (Simply sending a 'reply' to this message should work from most email
> interfaces, since that usually leaves the subject line in the right
> form.)
>
> If you do not wish to subscribe to this list, please simply disregard
> this message. Send questions to
> linux-audio-dev-admin(a)music.columbia.edu.
>
Regarding GUI toolkits that support accessibility directly there's some
information about Qt attached. Rosegarden and MusE both use Qt/KDE and
both support softsynths through the ALSA seq interface so there might
be some benefit in attempting to use these apps under Qt3.0 directly.
B
---------- Forwarded Message ----------
Subject: Re: [Rosegarden-devel] Fwd: [linux-audio-dev] GUIless friendly
applications
Date: Tue, 5 Nov 2002 17:54:34 +0100
From: Guillaume Laurent <glaurent(a)telegraph-road.org>
To: rosegarden-devel(a)lists.sourceforge.net
On Tuesday 05 November 2002 17:01, Richard Bown wrote:
> Can KDE/Qt help with accessibility?
Hard to tell. Nothing too serious at the moment I'm afraid.
http://doc.trolltech.com/3.1/keyfeatures30.html
"Accessibility
Accessibility means making software usable and accessible to a wide
range of users, including those with disabilities. In Qt 3.0, most
widgets provide accessibility information for assistive tools that can
be used by a wide range of disabled users. Qt standard widgets like
buttons or range controls are fully supported. Support for complex
widgets, like e.g. QListView, is in development. Existing applications
that make use of standard widgets will become accessible just by using
Qt 3.0.
Qt uses the Active Accessibility infrastructure on Windows, and needs
the MSAA SDK, which is part of most platform SDKs. With improving
standardization of accessibility on other platforms, Qt will support
assistive technologies on other systems, too. "
Now that's all nice and dandy but it doesn't say anything about what
this "accessibility information" is, which platforms it works with,
etc... Anyway, it will be there at some point, yes.
--
Guillaume
http://www.telegraph-road.org
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
-------------------------------------------------------
Patrick Shirkey wrote:
> CDs are an outdated medium that has survived because of the patent
> industry. If the multimedia companies didn't have so much invested
> into cd technology we would all own DVDRW drives by now. I hope it is
> just a matter of time before the prices are reasonable for small scale
> operations.
Umm, actually I'd heard nearly the exact opposite opinion voiced on more
than one occasion, namely, that higher-sample rates are basically an
audio industry ploy to sucker rich yuppies wth $5000 USD power
amps into buying "Sgt. Pepper" and "Are You Experienced" in yet another
format. Personally, I'm inclined to believe that, and I do consider
myself an audiofile. FWIW, I also run everything, even the DAT
machine (yes, I've still got one) at 44.1, even though my Delta can
handle 96, because I really don't like to deal with resampling, and
nothing I'm doing at this point has any likelihood of ending up on DVD-A
anytime soon.
'-dgm
Hi,
QJackConnect 0.0.1, a QT based patchbay for JACK, is available from
http://www.suse.de/~mana/jack.html or
ftp://ftp.suse.com/pub/people/mana/qjackconnect-0.0.1.tar.bz2
This is the first official release (some pre releases have been already
in use, but they were based on a bad hack) and its published under GPL.
Thanks to Kai Vehmanen for sending a patch which adapts QJackConnect to
the current CVS of JACK and finally resolves the bad hack.
I also wrote a small FM synthesizer which is both a (minimal) client to
JACK and the ALSA sequenzer system. jack_miniFMsynth.c is available from
the QJackConnect webpage as well.
Have fun !
Matthias
--
Dr. Matthias Nagorni
SuSE GmbH
Deutschherrnstr. 15-19 phone: +49 911 74053375
D - 90429 Nuernberg fax : +49 911 74053483