On Friday 03 August 2007, njcross(a)sbcglobal.net wrote:
> On Wednesday 01 August 2007 00:39, you wrote:
> > On Wednesday 01 August 2007, Florian Schmidt wrote:
> > > On Wednesday 01 August 2007, njcross(a)sbcglobal.net wrote:
> > > > Just to say thank you for lash_wrap. Seems to work as you stated. I
> > > > tried it with Ardour, Audacity and ReZound and as long as you save
> > > > your work before closing it works well. Thank you!
> > >
> > > A little caveat i found though:
> > >
> > > Apps that create their connections themself are not handled very well
> > > by lash_wrap. E.g. hydrogen, freqtweak etc... It would be cool if these
> > > apps had an option not to create any connections by themself on
> > > startup..
> > >
> > > Flo
> >
> > Erm, just see, jack connection restoring doesn't work with clients that
> > do not create the connections themself either.. hmm, weird.. I suppose i
> > need to debug some more ;)
> >
> > Flo
>
> I'm now having the same connection problems; or rather no connections are
> saved when using glashctl. hmm...
Ok, back to the ML's :)
try:
http://tapas.affenbande.org/lash_wrap/lash_wrap-0.4.tgz
It works here after a quick test.. I have added a --delay [-d] option which
defaults to 3 secs.. That is the time the wrapped client has available to
register jack and alsa ports.. ;)
So if your app takes longer to start than that it will still not work..
Tomorrow or so i will try to add an active scanning mode for jack client names
like for alsa seq client names..
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
On 7/25/07, Paul Winkler <pw_lists(a)slinkp.com> wrote:
> Pretty cool. Does JPEG 2000 handle float data?
>
> I'd love to be able to write an archive script for Ardour sessions
> that compresses the audio data losslessly, but FLAC won't do it.
I been thinking of the same thing... can't ardour handle FLAC files
natively ? a simple script in <you-name-it> language calling flac to
to compress the audio and change the session file to match the new
names should work I think.
Thoughts anyone ?
__________________
Marc-Olivier Barre.
On 7/31/07, Thomas Vecchione <seablaede(a)gmail.com> wrote:
> Dang it, I apologize to the list, I forgot this list DOES reply to the list
> when I hit reply, and nto reply to all.
>
> Seablade
I must admit this is a issue I wanted to raise for a while now...
For those of you who haven't heard, there has been a very long debate
on whether replyto munging was or wasn't a god practice. Each side had
a reference paper stating a number of pros and cons :
- http://www.unicom.com/pw/reply-to-harmful.html
- http://marc.merlins.org/netrants/reply-to-useful.html
The fight between Simon Hill and Chip Rosenthal finaly ended in 2001
when a new RFC obsoleting RFC 822 appeared, RFC2822.
Here's a paper from Neale Pickett stating the final story :
http://woozle.org/~neale/papers/reply-to-still-harmful
I strongly consider turning munging off on LAD and LAU. I know this
might start some flames, but isn't it good free software philosophy to
stick to the standards, especially when it comes to a recently
reviewed RFC ?
If someone can give me an argument that is not present in the 3
previously linked documents stating why we need to munge our headers,
I'll turn munging off next week.
Regards,
__________________
Marc-Olivier Barre.
Your favorite list administrator :-)
Hi,
I spent some time today integrating jack support into xwax. I have it
registering and creating ports but xwax uses file descriptors for it's
i/o's and I'm not sure about the best method to integrate the jack
callback system into that.
Any pointers for seperating the i/o's from the processing engine so that
we can keep alsa/oss support and also have jack too?
Cheers.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.comHttp://lau.linuxaudio.org - The Linux Audio Users guide
========================================
"Anything your mind can see you can manifest physically, then it will
become reality" - Macka B
[Appologies for the cross-posting]
[Please DON'T use reply-to-all to reply on this email]
Hi all,
With this I'm hoping to gather some data that can help us in convincing
the firewire device manufacturers that we are of some significance to
their sales (I'm actually wondering if we are...). So I would like to
ask everyone on these lists that has/considers/considered purchasing a
firewire audio device if they would be so kind as to answer the
following questionnaire.
** Those that have bought one or more firewire devices...
* can you provide which device(s), preferably with their GUID (can be
found out using gscanbus or sometimes on the device itself)
* Do they work with linux?
** Those that considered buying a firewire device:
* What device(s) did you consider buying?
* What device did you go for in the end (if applicable)?
* To what extent was the lack of Linux support a determining factor in
your decision?
** Those that consider buying a firewire device:
* What device(s) are you consider buying?
* How important is Linux support for you?
** any comments?
It would be nice if you would reply to this email with the answers
inlined with the questions. Please don't reply-to-all but reply to
pieterp(a)joow.be in order not to spam the mailing list with these
answers. It would also be nice if you left the subject line intact such
that I can auto-filter these messages.
Again, sorry to bother you guys with this, but it's a bit difficult to
convince manufacturers without some decent data.
Thanks,
Pieter Palmers
ffado.org
PS: If you know other freebob/ffado users that are not subscribed to
these list please pass this mail on.
Hallo Steve, list !
I just noticed, that the "triple band parametric with shelves" LADSPA
plugin generates a DC offset (tried version 0.4.15 and 0.4.14).
The offset is not always the same: first when I create the plugin, there
is no offset. Then I pressed play/stop (in ardour) and the DC offset was
here - also the amount of the offset is somehow changing when I play
with different parameters (but I did not find out a real correspondens).
However, when I use the "Single band parametric" and the shelves alone I
don't get an offest (which should be the same code ?).
I also made some other small additions to your plugin collection:
- single low and high shelving filters (see attached files): they are
the same code as in "triple band parametric with shelves", because I
often need only a single shelving filter
- in the "single band parametric" the slider to change the frequency was
linear, I changed this to logarithmic (file attached)
Maybe you could include those plugins/changes in your collection, at
least for me they are quite usefull.
LG
Georg
Hi!
I just tried to hack the small beginnings of basic jack_transport support in
a midi-sequencer. All it should be capable of is jack_transport_start and
stop.
I just opened a client (jack_client_open(package,JackNullOption,&status),
where status of of jack_status_t. and called jack_transport_locate(client,0)
and jack_transport_start(client), before starting the midi-playback and when
finished called jack_transport_close(client);
Only it won't even locate me to 0, it somehow fails there. Is there anything
special I have to consider? any special jack_function, subscribing me
elsewhere, opening a seperate thread?
Please, does anyone have any ideas on this?
Kindest regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
Hi Ben,
I tried to respond to your message, but there seems
to be a problem:
ben(a)glw.com
Delay reason: Connection reset by peer:
smtp.glw.com [66.222.83.247]
This has been repeated a number of times now.
To answer you question, when using floating point
it doesn't make a difference if all signals are at
around -40 dB. The ratios will be the same.
Ciao,
--
FA
Follie! Follie! Delirio vano è questo !
Hi,
(1) I've written a command line MIDI sequencer for lightweight systems and
am successful in making it work using the ALSA queue API. However, one
drawback of the API is its lack of callback functions. I wish to be able
to track events as they are drained by the queue.
(2) I know and have successfully worked on a work around whereby the
application itself subscribes to the output port so as to see events as
they are played.
However, I wish to be able to make the sequencer or player work without the
use of the ALSA queue nor the workaround in (2).
Here's the pseudo-code of the relevant MIDI player routine:
for (i = 0; i < number_of_events; i++)
{
usleep(event[i].delta_time_in_microseconds);
output_and_drain_event(event[i]);
}
This routine gives a non-bearable latency on 2.4 kernels but not so much on
2.6 kernels.
How could I get the app to <u|nano>sleep() in the most accurate way in
userspace without using the ALSA queue nor the extra subscription to an
output port? Or, is there a drain or output routine that supports
callbacks? If so, I will be grateful if you could point them out. I seem
not to find any output callback routine under the docs.
Thank you very much.
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, Diliman 1101, Quezon City
Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp
Hi,
i planned to write this for quite a while and finally got to it [though it's
not 100% working yet - It's a small program. If experienced unix hackers
might look over y use of waitpit i'd be happy :)]:
lash_wrap
It's a small program which can be used to "smuggle" non LASH apps into a LASH
session provided they meet some requirements:
- If they are jack clients, there must be a way of determining the jack client
name at startup time
- If they are ALSA seq clients the client ID must be known at client startup
time or their alsa seq name must be uniquely determined
- They must require a way to specify their state via the commandline (e.g. we
can tell ardour to load a certain ardour session at startup)
So here's how i would smuggle ardour2 into a LASH session:
lash_wrap -j ardour -- ardour2 ~/sound/ardour/brazil/brazil.ardour
The -j [--jack-name] option tells lash_wrap it must register the jack
name "ardour" with LASH. the "--" seperates the options for lash_wrap from
the commandline to start the program in question.
If we wanted also all ALSA SEQ connections of ardour to be restored we could
do:
lash_wrap -a ardour -j ardour -- ardour2 ~/sound/ardour/brazil/brazil.ardour
The -a [--alsa-name] option specifies a name which will be used to find out
the client ID of ardour by regularly searching all ALSA clients until one
named "ardour" is found. This ID is then passed to LASH.
CAUTION!!!! YOU MIGHT LOSE WORK!! READ ON:
- lash_wrap does not care for saving the state of the app in question. So
before hitting "close" in your favourite LASH session handler, be sure to
save the session in e.g. ardour manually.
- if the passed jack or alsa client names do not match for whatever reasons,
then connections won't be restored properly.
You have been warned. Nonetheless this might be useful for people who
otherwise use scripts to manage their audio sessions.
Download it here:
http://tapas.affenbande.org/lash-wrap
Regards,
Flo
P.S.: Apps like rosegarden are a bit difficult to handle, because they use
wrapper scirpts themself that exit immediately and confuse my little app
[into thinking the app exited, thus LASH thinks rosegarden has quit, too]
--
Palimm Palimm!
http://tapas.affenbande.org