Hello,
I'm writing a synth module on top of jack and I'm starting to contemplate stereo.
I looked up "pan law" and understand that center should be -3 db (or some say -3.5 or 4.5, whatever) given unity at panned hard L or R. It was said that in an ideal room I should be down -6 db in the center. That would mean linearly transitioning from unity gain to completely off as one pans, I *think* (-6 db in the center = .5).
So that's one (very easy) way to go...
There was also mention of "equal power". Since power is proportional to signal squared, this means with parametrized L and R functions
L(t)^^2 + R(t)^^2 = 1, 0 <= t <= 1
We need an f(t) such that f(t) = L(t) and f(1-t) = R(t).
I played around this for awhile and using the sum of the square of sin and cos etc I got an f(t) of
f(t) = cos( pi * t / 2 ) (details available on request)
So L(t) = cos(t * pi / 2) and R(t) = cos((1 - t) * pi / 2)
And that seems to work out correctly.
Is this equal power version worth spending the processing cycles on? I intend to make pan envelope and LFO controllable so it's not going to be the case that the pan value can be thought of as relatively static.
Thoughts?
Thanks
Eric
PS now that I know what I'm looking for web search turned up this:
http://www.midi.org/techspecs/rp36.php
Hey all,
I've began learning about the LADSPA standard, read the comments in the
header, read the ladspa.org info,
but still I wouldnt know where to start with writing my own code to make a
plugin process a buffer.
So my request is as follows, is there a "here's 20 lines of code to process
a buffer" tutorial somewhere?
I've downloaded the SDK, but reading trough the "applyplugin.c" code
confused me more than it helped...
800+ lines is more than I can understand in one go.. :-)
Cheers for any suggestions.. -Harry
The Problem:
I have a poor wireless card in some notebooks. This card is a hard to work,
but after kernel 2.6.37-rc2 is come to working, some features is add to
laptop and video card now work in built in.
Some apps cannot work so good, and i would add RT patch in this kernel to
get rtprio
I make some tries with patch-2.6.33.7-rt29 but Im fail, so the question is:
How i can apply the rt patch in the kernel 2.6.37+ ?
--
yermandu
It was a previous discussion "Musescore "music trainer"?", about
polyphonic audio to MIDI recognition. I found a windows program that
claim to archive good results : TallStick TS-AudioToMIDI
On this webpage : http://tallstick.com/webhelp/algorithm.htm,
they wrote some interesting claims :
- "They (3 of the 4 algorithms) all are based on the set of oscillator
circuits named sensors. Each sensor gets wave signal as input and
produces some reply. Sensor's reply is a value proportional to the
amplitude of component with frequency about equal to sensor's
resonance one."
This is what I call "filtre en peigne" in french. Comb filter. Each
"teeth" of the comb will test for one frequency.
- After sensor's output is multiplied on correspond Equalizer values,
it arrives on Spectrum Window. All these methods analyze spectrum
data at each instant of time from left to right (from low to high
pitches). When spectral maximum is detected it assumed to be
fundamental frequency of note. This assumption is tested by comparing
spectra to Harmonic model setting. After this, if assumed note is
greater than Threshold value then note accepts, otherwise rejects. If
note is accepted, all it's spectral components are subtracted from
corresponding components of whole spectra.
This show that the whole algorithm is more complex than a simple
recursive filtering. They take in account the spectra of the music. You
can (and must) assign the instruments that play the music, before to
made the conversion.
Ciao,
Dominique
--
"We have the heroes we deserve."
Last year I spent time being confident with arduino projects (music related, sending MIDI messages to a hard synth, etc).
I would hack that when I plug my arduino (USB), it appesars in aconnectgui list, the same way that I plug my Axiom 25 and magically it appears in aconnectgui.
I suppose that this task could be called "to program an alsa driver for arduino", isn't it?
If someone can point me in the right direction...
TIA,
Joan Quintana
http://wiki.joanillo.org
> I'm not too sure what I'd call it. Thiago Teixeira called it ttymidi:
> http://www.varal.org/ttymidi/
> Should do exactly what your looking for I think. Just run his program, and any USB/Serial > device
> can send data to ALSA MIDI. :-)
> Cheers, -Harry
> PS: Might be nice to send the author a "thanks" if you like it
Thanks for make me remember ttymidi. I tried it and is perfect for the purpose to connect arduino to fluidsynth.
Returning to the problem..., I imagine something like plugging arduino and appearing automatically in aconnect. Maybe the solution is to hack the FTDI driver. FTDI is the chipset that converts serial to USB, and needs an FTDI driver to create a virtual COM port: /dev/ttyUSB0. The solution could be hacking the FTDI driver with the ALSA libraries driver and making it an ALSA sequencer port.
Joan Q
Hi,
I'd like to announce that my LV2 port of the famous mda e-piano
plug-in is ready for download! [1]
When I was checking out the mda-lv2 ports, I noticed that the
instruments were not actually playable. I could not get them to work
in either lv2_jack_host or in Ardour2 or Ardour3.
So , here is the first and only (to my knowledge) native LV2 port of
the mda e-piano. There is no GUI yet, but once I figured out how to
add a GUI I'll be adding one.
I'd be very happy to receive comments and suggestions on the code.
My next target will be the mdaPiano plug-in---I might actually start
soon when the GUI stuff causes me too much of a headache...
Best,
Rekado
_____
[1] http://github.com/rekado/lv2-mdaEPiano
I noticed that bristol-0.40.7-7 updated due to the following security
update. What got me curious is what kind of security issue could
running bristol possibly pose?? -- none on it's own, but another rogue
package could exploit this issue ...
https://bugzilla.redhat.com/show_bug.cgi?id=638376
.................
Raphael Geissert conducted a review of various packages in Debian and found
that bristol contained a script that could be abused by an attacker to execute
arbitrary code [1].
The vulnerability is due to an insecure change to LD_LIBRARY_PATH, and
environment variable used by ld.so(8) to look for libraries in directories
other than the standard paths. When there is an empty item in the
colon-separated list of directories in LD_LIBRARY_PATH, ld.so(8) treats it as a
'.' (current working directory). If the given script is executed from a
directory where a local attacker could write files, there is a chance for
exploitation.
In Fedora, /usr/bin/startBristol re-sets LD_LIBRARY_PATH insecurely:
declare -x
LD_LIBRARY_PATH=/usr/lib:/usr/local/lib:${LD_LIBRARY_PATH}:${BRISTOL}/lib
A solution is to patch the script to test if $LD_LIBRARY_PATH is set first
before attempting to modify it:
if [ -z ${LD_LIBRARY_PATH} ]; then
export LD_LIBRARY_PATH=/usr/lib/foo
else
export LD_LIBRARY_PATH=/usr/lib/foo:${LD_LIBRARY_PATH}
fi
This issue has been assigned the name CVE-2010-3351.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598285
...........................
Niels
http://nielsmayer.com
