Hello guys!
I would like to ask any of the developers who might be interested to help a
musician out!
Original Kluppe developer seems very busy these days. And his programm lacks
two things I really need for my musical work.
I am ready to pay for the work. All the details below.
*1. Feature 1 - random play.*
When on Windows, I wrote a simple programm for myself, called Tape Loops. It
could play sounds either once or in a loop. The special function which I
added to it was "random play". What it did was allow you to define a period
of time in seconds. And the programm would trigger the sound randomly
somewhere within this period. So, if the period is 20 seconds, the programm
would play the sound either in 5 seconds, or in 10 or in 7 or in 20. When
the sounds stops playing, the timer is reset and the program once more
chooses a random moment to trigger the sound within the given period. By
changing the period the musician can make the sound get triggered more often
or less often.
The demo of how this program works can be viewed here:
http://www.louigiverona.ru/?page=projects&s=software&t=tapeloops&a=tapeloop…
It is a great feature - it helps a lot an ambient composer like myself and
is greatly useful for installations.
On Linux I have tried some programming, but even setting up JACK is very
difficult for me, I am absolutely not a strong desktop programmer. So
writing something like that from scratch on Linux is not realistic for me. I
tried Kluppe, which is the closest thing, it is a great piece of software,
but I studied the code for several days, tried some things, but apart from
changing the colors, I do not seem to be able to do anything meaningful.
So I would like to ask someone to do this job for me. To add a timer to a
kluppe looper and to allow this "random play" mode, where the musician can
put a looper into random play mode and define the period.
*2. Feature 2 - basic midi control.*
Looking through Kluppe code, I saw that a lot of midi is already done, but
it is not "attached" to the controls. I might be wrong and there may be more
work than it seems, but anyway. I would want to be able to assign midi
control to triggering loops, volume and panning - at least that. Otherwise,
Kluppe is very difficult to use in a live performance.
However, instead of proposing to allow to create separate controls for each
looper like they have in SooperLooper, I would advice (and actually, ask for
this feature to be implemented in such a manner) to instead go for the
Selected looper scheme. So that one would not need a dozen of knobs to
control things. There should be an ability to have one "Selected" looper.
Similar to what Dj Traktor Studio has. So you are binding midi not to a
definite looper, but to the Selected looper, and thus you would require only
two knobs (vol, pan) and three buttons (play/stop, Prev looper, Next
looper).
*3. Payment.*
I understand that all of the above might be not as simple as it seems to me
now. I would be willing to pay, as much as I can. I am able to pay through
PayPal. I do not know how much money is a normal pay for such work, but I
think something can be arranged. If I am not able to pay up instantly, I am
willing to pay for several months in a row to cover the necessary expenses.
I will also ask around on forums if someone will join me and also donate
some money - while my random play function is probably too specific and is
only something for me, midi control in Kluppe is something I believe many
people would want.
Thank you for your attention and I hope someone gets interested in the
request!
Louigi Verona.
http://www.louigiverona.ru/
Hello everybody!
When using an LV2 synth within a sequencer, I was told that the host has no
way to access audio which is produced by the plugin so such a basic thing as
rendering your whole project to wav appears to be impossible.
I want to ask if this is true and whether this can somehow be changed. In my
opinion, if the above is true, this is a very serious limitation of LV2.
--
Louigi Verona
http://www.louigiverona.ru/
I've been long annoyed by alsa-tools' envy24control (*) lack of
peak-level indication in it's metering, and the non-implementation of
its "Reset Peaks" button:
https://bugzilla.redhat.com/show_bug.cgi?id=602903
I've fixed that annoyance. Now, a small white line appears above the
highest level on each meter, and can be reset via "Reset Peaks"
button.
Original source:
http://git.alsa-project.org/?p=alsa-tools.git;a=blob_plain;f=envy24control/…
Patch:
http://nielsmayer.com/npm/602903.patch
To run this version of envy24control grab the most recent stable release (
ftp://ftp.alsa-project.org/pub/tools/alsa-tools-1.0.23.tar.bz2 ) or git pull
from trunk of the "alsa-tools" project (
http://alsa-project.org/main/index.php/GIT_Server ).
After unpacking and assuming you've got the patch in ~/602903.patch do:
>> cd alsa-tools-1.0.23
>> cat ~/602903.patch | patch -p1
it should give message "patching file envy24control/levelmeters.c" ...
follow the directions to compile alsa-tools....
Can whoever's in charge of these things commit this change "upstream"
and get it to propagate to the distros?
Alternately, give me commit access and I'll do it myself, if people
agree this patch is worth having.
Next steps:
(1) Think about building-in meter ballistics from Fons Adriaensen's
jkmeter ( http://www.kokkinizita.net/linuxaudio/downloads/jkmeter-0.4.0.tar.bz2
). Which helps implent Bob Katz' "K System" (
http://www.digido.com/level-practices-part-2-includes-the-k-system.html
). Although it probably most makes sense to implement such metering on
the main "digital mixer" meter of envy24control, if it's not too
inefficient, I'd want it available on all meters, despite the warning
from Fons ( http://old.nabble.com/First-release-of-jkmeter-td18798950.html
).
> This is the type of meter you want for live recording,
> mixing and mastering. It probably makes no sense to
> use it on all tracks of a DAW, where keeping digital
> level within limits is the main purpose of metering.
(2) Fix https://bugzilla.redhat.com/show_bug.cgi?id=602900 which
causes 'envy24control' to crash when given "-D" argument.
and behave incorrectly when given a correct non-numeric name for an
audio device: e.g.
>> envy24control --card M66
>> invalid card type (driver is USB-Audio)
>> envy24control --card M66 --device M66
>> Segmentation fault (core dumped)
(3) Apply more reasonable defaults and automatically size to correct
dimensions. I use, for example:
>> envy24control --card 2 --outputs 4 --input 4 --pcm_output 8 --view_spdif_playback --midichannel 1 --midienhanced --window_width 1275 --tall_eq_mixer_heights 1 &
(4) Add midi output, in addition to midi input, which would monitor
the hardware peak metering from the ice1712
("amixer -c M66 cget iface=PCM,name='Multi Track Peak',numid=45")
and output a MIDI note-on on the corresponding MIDI channel whenever a
specified threshold value was exceeded. This could be used to
implement "automatic gain control" in association with the
midi-controllable ADC gain provided by envy24control.
Niels
http://nielsmayer.com
PS: (*) http://alsa.opensrc.org/index.php/Envy24control
Cards supported by this fix:
* M Audio Delta 1010
* M Audio Delta 1010LT
* M Audio Delta DiO 2496
* M Audio Delta 66
* M Audio Delta 44
* M Audio Delta 410
* M Audio Audiophile 2496
* TerraTec EWS 88MT
* TerraTec EWS 88D
* TerraTec EWX 24/96
* TerraTec DMX 6Fire
* TerraTec Phase 88
* Hoontech SoundTrack DSP 24
* Hoontech SoundTrack DSP 24 Value
* Hoontech SoundTrack DSP 24 Media 7.1
* Event Electronics, EZ8
* Digigram VX442
* Lionstracs, Mediastaton
* Terrasoniq TS 88
Hello.
Just a follow up to something I said a while back.
I think Gene H. was saying he couldn't get audio
and I had replied that I disabled Pulse and it
appeared to be working.
But even after disabling Pulse, sometimes I still was
not getting audio in Flash on YouBoob etc.
When I did have audio, I noticed that every video's
audio seemed slower and lower in pitch.
I was fooled into thinking that the owners of the
videos had somehow remixed them at lower
pitches or something.
It turns out that Flash wants to play everything
at a 48000Hz sample rate.
Since my audio card is an Envy24 based card,
it always boots up in 44100Hz sample rate mode.
So now, before I play Flash videos, I must open the
envy24control mixer and set the sample rate to 48000Hz.
It works every time now !
Can someone explain the process of how Flash plays audio,
and how to force it to use 44100Hz?
I'm confused because at 44100Hz the audio is in sync
with the video, yet it is lower in pitch and slower.
Does this mean Flash is really playing the video slower?
Thanks. Tim.
On 07/21/2010 07:24 PM, Fons Adriaensen-2 wrote:
> On Thu, Jul 22, 2010 at 01:05:01AM +0200, Philipp Überbacher wrote:
>
> > I think the word loudness is a problem here. Afaik it usually refers to
> > how it is perceived, and twice the amplitude doesn't mean twice the
> > perceived loudness. It may mean twice the sound pressure level, energy,
> > or intensity (if we ignore analogue anomalies, as you wrote in some
> other
> > answer).
>
> Subjective loudness is a very complex thing, depending on the
> spectrum, duration, and other aspects of the sound, and also
> on circumstances not related to the sound itself.
>
> For mid frequencies and a duraion of one second, the average
> subjective impression of 'twice as loud' seems to correspond
> to an SPL difference of around +10 dB.
>
> I often wondered what criterion we use to determine which
> objective SPL difference sounds as 'twice as loud'. We don't
> have any conscious numerical value (there may be unconscious
> ones such as the amount of auditory nerve pulses, or the amount
> of neural activity), so what it this impression based on ?
>
> The only thing I could imagine is some link with the subjective
> impression of a variable number of identical sources. For example
> two people talking could be considered to be 'twice as loud' as
> one. But that is not the case, the results don't fit at all (it
> would mean 3 dB instead of 10).
>
Hi Fons, I'm a fool to even try to answer this question.
But I couldn't resist...
Let's suppose we have two sounds A and B,
and sound B has been measured as being twice as loud as A,
by somebody. In order to be able to say that, that person needs
some kind of reference measurement unit, the equivalent of a
measurement stick. That unit has to satisfy two requirements.
It has to be big enough, so that people can agree some difference
is being measured, and it has to be small enough, so that a multiples
of that unit fit into a realistic range. There is a requirement of maximum
precision (the smallest value we can measure), and a requirement of
minimum precision. The question is, what kind of measurement stick
is being used by that person.
First of all, we can assume that the length of that stick will be depend
on the range of possible input values that we observe, and that we want
to measure. If we want to measure the size of a road, we will probably
use kilometers, instead of meters. In the same way, when our ears want
to measure the amplitude of a sound, our ears will use smaller or bigger
units, depending on the ranges observed. What are the ranges we observe?
Let's assume that humans are perfect, and observe everything that we
can observe with SPL meters. We could do a statistical investigation
on a number of people, and make charts of everything they hear.
In these charts we would see what frequencies they are exposed to,
and what the minimum and maximum SPL's are for that frequencies.
After more analyses, we would have one chart that could be
representative for most people.
>From that chart we could get an estimate of the size of the measurement
unit. Frequencies with with bigger SPL variations would be measured
with bigger units, and visa versa. And from this we could deduce what
the minimum precision is for a certain frequency, when we say it is twice
as loud. To satisfy the requirement of maximum precision, we should
take into account the smallest observable differences for every frequency
in the spectrum.
now you can kill me :-)
Greetings,
Lieven
People today aren't able to do a good stereo or mono mix, e.g. because
of the loudness war, but they are thinking of doing 3D mixes.
I'm unable to follow this strange evolution.
We all have 2 ears and 1 brain that has to do a lot of work, regarding
to information from the sense organs. The brain needs to do math because
usually the left and right ear are not equal, so even when wearing a
head phone the brain needs the context of the situation and the perfect
natural loudness etc. for this context.
All thoughts about doing 3D are useless until we aren't able to connect
electrodes directly to our brains and to have a rimming regarding to our
brains.
As long as Cochlear implant isn't good, any try to do 3D mixing is
laughable, resp. a pain, just try to watch AND hear a modern film, it's
a torture.
There are some good mixes for stereo and mono, but at least I never
heard a valid mix with more but one ore two channels.
On 07/22/2010 03:36 PM, Fons Adriaensen-2 wrote:
> On Thu, Jul 22, 2010 at 09:31:09PM +0200, lieven moors wrote:
>
> > Hi Fons, I'm a fool to even try to answer this question.
> > But I couldn't resist...
>
> :-)
>
>
> > Let's suppose we have two sounds A and B,
> > and sound B has been measured as being twice as loud as A,
> > by somebody. In order to be able to say that, that person needs
> > some kind of reference measurement unit, the equivalent of a
> > measurement stick. That unit has to satisfy two requirements.
> > It has to be big enough, so that people can agree some difference
> > is being measured, and it has to be small enough, so that a multiples
> > of that unit fit into a realistic range. There is a requirement of
> maximum
> > precision (the smallest value we can measure), and a requirement of
> > minimum precision. The question is, what kind of measurement stick
> > is being used by that person.
>
> Not really. If A is 'twice' B, either A or B can act as the reference.
Yes, but we can never agree that A is twice B, unless we agree on
how precise the measurement could/should be.
>
> I'm pretty sure that if you'd do the experiment to find out when
> people think that an object B is twice as big as another object A
> (without introducing optical illusions), you'd find that it's quite
> close to a factor of 2. This is because we can easily imagine two
> A's side by side, which would be 'twice as big' as one A.
I don't think this is easy. Imagine a ruler lying on your desk, and
try to imagine the point where the ruler would become twice as
long. I think you will find that your brain is continually adjusting
that distance, and that it requires significant effort.
It also occurs to me, that by doing this, I am actually
determining the smallest observable difference, and that this
distance is proportionate to the length of the ruler.
>
> Can we do something similar with 'loudness' ? As I wrote, the
> only option I see is to consider two equal sources to be 'twice
> as loud' as one of them, but that doesn't work out.
It could work if we would agree on it. But apparently our brains
have made up their own mind :-)
That's why I propose to reconsider how we look at measurement.
The process of measuring might not be as simple as we think.
>
> Given this, what you write does make sense - there must be some
> 'stick' rather than a real comparison of A to B. But what is it
> based on ? If most people do agree on some value for 'twice as
> loud', even with a large variation, there must be some physical
> ground for this. But what is it ? And a related question: iff
> there is some 'unit' even a variable one depending on frequency
> etc., why can't we imagine that unit ? Why don't we 'see' the
> stick ?
When we see the length of something, we don't see the stick either.
The only thing we see is that one thing is longer than the other.
The stick is just a short thing, which we can compare to all other
things. But even when you agree on such a reference, you still have to
go through the process of measuring.
The problem of 'twice as loud', shows us that we can measure things
even without an agreed-on unit. Somehow we are able to dynamically
create that unit when we need it.
This is how it could work for example:
we have a range, and something within that range: | x
|
we try to cut the range in halves and keep the part with x: | x |
The precision of cutting in halves is based on the smallest
observable difference between the two halves, and is
proportionate to the size of the range. (yes I know this is
a problematic statement, I have to think more about this)
We do the same thing
again: | x |
Now, if we would halve the range again, we would be unable
to distinguish x from that point, and we have some kind of
measuring
stick: |
| | | |
> > First of all, we can assume that the length of that stick will be
> depend
> > on the range of possible input values that we observe, and that we want
> > to measure. If we want to measure the size of a road, we will probably
> > use kilometers, instead of meters. In the same way, when our ears want
> > to measure the amplitude of a sound, our ears will use smaller or
> bigger
> > units, depending on the ranges observed. What are the ranges we
> observe?
> > Let's assume that humans are perfect, and observe everything that we
> > can observe with SPL meters. We could do a statistical investigation
> > on a number of people, and make charts of everything they hear.
> > In these charts we would see what frequencies they are exposed to,
> > and what the minimum and maximum SPL's are for that frequencies.
> > After more analyses, we would have one chart that could be
> > representative for most people.
>
> This is basically what has been done more than 50 years ago, with
> the known results: the objective ratio corresponding to 'twice as
> loud' depends on frequency, absolute level, etc.
>
> > From that chart we could get an estimate of the size of the measurement
> > unit. Frequencies with with bigger SPL variations would be measured
> > with bigger units, and visa versa. And from this we could deduce what
> > the minimum precision is for a certain frequency, when we say it is
> twice
> > as loud. To satisfy the requirement of maximum precision, we should
> > take into account the smallest observable differences for every
> frequency
> > in the spectrum.
>
> 'Smallest observable difference' has been measured as well. It should
> relate in some way to 'twice as loud', but I haven't verified this.
> OTOH, knowing the smallest observable difference does not help to
> define what 'twice as loud' is supposed to be.
As I said above, I think it plays a major role, in our ability to
measure things
Could you elaborate on this a little bit more?
Greetings,
Lieven
>
> Another poster mentioned that he found it quite difficult to work
> out what 'twice as loud' means for him - and I do believe that is
> touching on the real problem: if you start *thinking* about it
> rather than just following your 'gut feeling', how sure can you
> still be of your impression of 'twice as loud' ? How stable is it
> in the face of doubt ?
>
> Keep on thinking !
>
> Ciao,
>
> --
> FA
>
> There are three of them, and Alleline.
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@...
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
---------- Forwarded message ----------
From: Marc Hohl <marc(a)hohlart.de>
Date: Sat, Jul 24, 2010 at 8:19 PM
Subject: [tablatures] [Request/Bounty] Tablature bends
To: Lily-Devel List <lilypond-devel(a)gnu.org>, "tablatures(a)lilynet.net" <
tablatures(a)lilynet.net>
Hello all,
after about half a year I have to admit that I don't have a) the time
and b) the programming skills to implement bends in lilypond[1]. Sorry.
Bends are important for guitarists, so I offer 75$ for this issue and
I am posting to the tablature list, because perhaps someone else there
is willing to donate some money too, to get this task done.
During winter 2009/2010, Carl and I discussed the syntax and implementation
details very intensively in about a dozen mails or so, and as things got
nailed down, I wrote a roadmap how the bend engraver and the tab note head
engraver have to be built/extended. There is also a file bend.ly
which uses slurs to mimic bends - the graphic routines for bends are already
there,
so I offer my help providing and explaining the roadmap. A skilled developer
should have no problems to code the new engraver and transform the graphic
routines
into c++ code.
During the bend.ly story, I got in touch with developers of tuxguitar, so I
think
the whole bend story will make lilypond more attractive as a front end to
tuxguitar users and of course to professional music typesetters working on
contemporary
guitar music.
Greetings
Marc
[1] It was really hard for me to accept b), but to be honest, I still
struggle
with some basic concepts of c++ in combination with lilypond, which is
*very*
frustrating.
I suggested this idea on linux-audio-dev list: http://lists.linuxaudio.org/pipermail/linux-audio-dev/2010-July/028590.html, but still have no any answers.
Unfortunally, as I just saw, it was included into other thread: http://lists.linuxaudio.org/pipermail/linux-audio-dev/2010-July/028588.html, I can guess, it is why there are still no answers. I will not confuse, if this message will also be included into some other thread... At least, you could point me other reasons to not answer to that post.
It causes a slight letargy, when question hits into black hole.
Initially I planned to make a special controller for Aeolus, which should allow to write stops toggling to sequencer, but then thought, that it is like a sycle building, and a such thing could be more compact - e.g., controller could be integrated into instrument GUI. A feature to generate correct MIDI signal, written to sequencer, could be disabled, even on the fly, to save performance.
...continuation of truncated mail (does anyone know why this happens?)
>From that chart we could get an estimate of the size of the measurement
unit. Frequencies with with bigger SPL variations would be measured
with bigger units, and visa versa. And from this we could deduce what
the minimum precision is for a certain frequency, when we say it is twice
as loud. To satisfy the requirement of maximum precision, we should
take into account the smallest observable differences for every frequency
in the spectrum.
Greetings,
Lieven
