Hi
Anybody knows any software that enable MP3 timestretch in real time?
I want no file conversions.
In addition, I prefer a software that process the MP3 stream and not the
stream MP3 after decoding process. Anybody knows any algorithm for this?
Sorry by my english faults.
Regards, Suzana
Hi all,
Ok, so I'm playing with osc (currently doing gui->app communication with it)
but all my individual apps still talk midi between them. This is quite
cumbersome, as I want to start having lots of controls that midi doesn't
support - and I don't really "think" in midi these days anyway.
Is there a case now to ditch midi support and go with osc for everything? I
see midi messages are a type within osc anyway - is it fairly straight forward
to be backwards compatible this way?
cheers,
dave
Greetings:
I wrote to Joerg Anders, the author of NoteEdit, and he confirmed that
he is leaving off development of NoteEdit. Though I disagree with his
assessment of a possible Linux Finale, it's certainly his right to stay
with or go away from the helm of NoteEdit development, and he can use
any reason he prefers.
I have *no* confirmation regarding any Linux development at all from
Coda Music, the manufacturers of Finale. Unless someone knows more, I'd
say it's an unfounded rumor. I've read that some users have run Finale
under Wine: I can get it to open but it doesn't work after that.
There's some discussion whether to keep it in AGNULA and whether
AGNULA members might want to take over the development of NE. I realize
that NE has some possibly irritating dependencies, but I must add that
it is a unique Linux music notation editor with a well-evolved set of
features and an active user base.
I'm uneasy about the implications that mere rumor compelled Joerg to
abandon NE, though as I said, I respect Joerg's wishes and his
accomplishments with regard to NE. I'm confused as to why Finale's
presence might force a developer to consider his own work a closed case.
After all, Finale is expensive, closed-source, and not necessarily
suited to everyone's work methods. NE is free software, open-source, and
works nicely for me. I would hate to see it disappear.
Joerg said that since sources are available anyone can continue with
NE development. I hope that happens.
Best regards,
dp
hi all,
i'm considering to add lock free queue support to packet forth, just to
follow the hype, and maybe also because i like the concept. but i'm
wondering if it would make much sense to go through all the trouble with
fast mutexes being available in 2.6
in other words, how much better (apart from being more elegant) are lock
free structures wrt a mutex approach where there is a minimal system
penalty? (not many collisions) did anyone look into this? or have i not
been lurking properly? ;)
cheers
tom
Ingo Molnar <mingo(a)elte.hu> wrote:
>
> I took a
> look at latencies and indeed 2.6.7 is pretty bad - latencies up to 50
> msec (!) can be easily triggered using common workloads, on fast 2GHz+
> x86 system - even when using the fully preemptible kernel!
What were those workloads?
Certainly 2.6+preempt is not as good as 2.4+LL at this time, but 2.6 isn't
too bad either. Even under heavy filesystem load it's hard to exceed a 0.5
millisecond holdoff. There are still a few problem in the ext3 checkpoint
buffer handling, but those seem pretty hard to hit. I doubt if the `Jack'
testers were running `dbench 1000' during their testing.
All of which makes me suspect that the problems which the `Jack' testers
saw were not directly related to long periods of non-preemption in-kernel.
At least, not in core kernel/fs/mm code. There have been problem in the
past in places like i2c drivers, fbdev scrolling, etc.
What we need to do is to encourage audio testers to use ALSA drivers, to
enable CONFIG_SND_DEBUG in the kernel build and to set
/proc/asound/*/*/xrun_debug and to send us the traces which result from
underruns.
As for the patch, well, sprinkling rescheduling points everywhere is still
not the preferred approach. But adding more might_sleep() checks is a
sneaky way of making it more attractive ;)
Minor point: this:
cond_resched();
function_which_might_sleep();
is less efficient than
function_which_might_sleep();
cond_resched();
because if function_which_might_sleep() _does_ sleep, need_resched() will
likely be false when we hit cond_resched(), thus saving a context switch.
Unfortunately, might_sleep() calls tend to go at the entry to functions,
whereas cond_resched() calls should be neat the exit point, or inside loop
bodies.
Hello,
I'm using PortAudio library to try to program a loop-sampler software
under Linux (and perhaps Windows). Actually, I would like to make a
console-based software. I would like to know how could I manage entries
from keyboards. I think that ncurses lib is a good choice. But my
problem is in algorithm term.
I think that making a code in the main() like this:
while (true) {
if (key is pressed) {
switch (value of the key) {
case 'A':
proceed to FFT ;
break;
case 'B':
proceed to time stretch
break;
case 'C:
reduce volume
break;
...
...
}
}
wait for a certain time;
}
is not a good idea. I know that with MFC there is event management with
WM messages. I don't know what is there under Linux, especially in
console-based apps. With GUI libs like GTK, no problems I think. But
what about console-based apps?
Does anybody knows some internet sites, or some other libraries, or some
methods (perhaps multithreads? seems to be heavy for just event
managements...). I have look at ncurses docs but they shows an example
with a kind of loop like the one I just talk about above. Any advice is
welcome
Bye.
hi erik,
i've got a question regarding type combinations in libsndfile:
SF_FORMAT_FLOAT | SF_ENDIAN_CPU works with SF_FORMAT_AU on any
platform, which is great. but it doesn't work with neither aiff nor
wav. i expected that it would work with one of the both formats,
depending on the host endianess.
is there a special reason why it does not?
some other questions regarding string data:
snd does not explicitly allow using string data in the file format.
however, i remember that it was done in the old NeXT days by
increasing the data offset and using the space in between for a
comment. do you think this could be implemented in libsndfile for the
SF_STR_COMMENT thing or is that just too non-standard?
with SF_FORMAT_AIFF, i can't write string data to the file in SFM_RDWR
mode. the call to sf_set_string() succeeds, but the actual data in
the file is not changed. the call to sf_set_string() succeeds even
when the file is in SFM_READ mode.
with SF_FORMAT_WAV, a file with string data can't be opened with
SFM_RDWR anymore. this means there is no way to change the audio data
or the comment of the file without copying it? i guess there is a
special reason for that...
thanks very much for your patience...
bests,
martin
Greetings:
While doing some research on VST/VSTi technology I checked the
Wikipedia page for "VST". It's a good informative page, and there's even
an entry regarding the fst/libfst project. However, there was no mention
of Kjetil's vstserver and its clients. There is now.
It occurred to me that while we're laboring over where & whether to
use wikis, there's already a place for us to get some more information
out to the public: the Wikipedia. I don't know how many other Linux
audio projects are detailed. Ardour, ALSA, Pd, and others are already
there, but I don't know how up-to-date that material is. So, would-be
documenter writers, avail thyselves of this opportunity and start
hitting the wikipedia ! Add new entries, correct the old ones, bring 'em
up to date, but just do it ! ;-)
Thank you for your attention. We now return you to your regularly
scheduled programming.
Best,
dp
Hi.
I recently wrote ALSA PCM and seq support for BRLTTY[1].
However, the fact that libasound.so.2 lives in /usr/lib does
present a little problem for us. BRLTTY needs to be run as
early as possible during startup, most likely before /usr is
even mounted. Linking against -lasound the traditional way therefore is quite
a bug, since the executable now doesn't start anymore if
/usr is missing.
We've solved this now by dlopen() and dlsym()'ing all the
symbols we actually need, and call our private function pointers instead
of the real library symbols. However, this solution is kind
of icky. At the same time, we wrote support for QNX, which
seems to have a early fork of ALSA as the QNX Sound Architecture (also
called libasound). QNX apparently already puts its
libasound.so in /lib, most probably because of this
problem.
I'd like to ask the community what you think about
moving libasound from /usr/lib/ to /lib/? With OSS, that
wasn't a problem at all, since the ioctl calls were simple
enough that there is/was no need for a wrapper lib. But
since ALSA kind of relies on that, wouldn't it make more
sense to have the lib in /lib so that early boot programs
can output sound too?
--
CYa,
Mario
Hi,
I've posted the following message in Rosegarden-devel mailing list, and
Michael pointed me to an old thread from you about the same subject:
http://www.mail-archive.com/linux-audio-dev@music.columbia.edu/msg03322
Attached is a little program summarizing what I have found about the file
format at this moment. I would like to know if you have more information,
ideas or want to collaborate in this task.
Regards,
Pedro
On Sunday 29 August 2004 01:50, Pedro Lopez-Cabanillas wrote:
> Hi,
>
> I have many old songs, stored as Cakewalk "WRK" files, and I don't use
> Cakewalk or Sonar anymore. I'm not planning to do so in the future, 'cause
> I'm sure I will use Rosegarden. Of course.
>
> So, I need to convert my old WRK files to Rosegarden. But the WRK file is a
> closed format, and not publicly documented. It will be necessary to reverse
> engineer it, to rescue my old loved melodies along with the pile of shit.
>
> My plan is to first write a 'cake2rg' standalone utility, to start learning
> the file format and meanwhile to produce some practical results. After
> that, I hope to be able to import the files directly into Rosegarden. This
> won't happen before 1.0-final.
>
> If somebody had the same idea and has the work almost finished, please let
> me know ;-). Let's avoid duplicated work.
>
> Comments, please.
>
> Regards,
> Pedro