I wrote:
>> Maybe I made a mistake there, confusing a plugin chain with analog
>> latencies. Ah but then, isn't a plugin chain like a 'bucket brigade'?
>> Each stage can't know what the previous stage does to the signal until
>> that previous stage has processed a whole buffer.
>> ("He said, waiting to be clobbered by the responses.")
>Oops, yeah that happens, but all within one process cycle.
>Each plugin in the chain is run in succession on the data, right?
>My mistake. Must be tired, the ol' brain wanders...
I have a question, sort of related to that latency discussion:
Plugin 'run' length need not be related to audio buffer size, right?
I'm thinking of breaking up my 'single-run-per-process' into multiple
'run-lengths-between-control-or-program-changes-or-midi-events',
per process.
I know dssi docs mention doing this in regards to program changes
'between notes', but don't specifically mention handling control changes
or midi events that way, but it seems reasonable.
So not only will I get more or less 'sample accurate' control and program
changes and midi events, but processing each control's successive changes
won't take so long from waiting for the next process cycle in order to
set each change (I found when processing a string of dssi-vst osc control
change notifications for one control, the vst expects *all* of the changes to
be sent back to it via the ladspa control port, so the quicker the port value
can be changed, the better, that's why I want to break up the runs).
Is this a good method?
I'm also asking because...
If I carry this logic to an extreme, what might be wrong with
using say 128 'single sample' runs, for an audio buffer size of 128?
Can plugins handle 'single sample' (or even dynamically varying runs)?
My proposed method implies this would actually happen, if control or
program changes or midi events needed to occur very close together.
Thanks. Tim.
Hello,
Ashes to ashes, dust to dust, funk to funky. Yawn. Cut the non-sense,
there's no burial service nor Bowie's song here. Just blowing some aging
stuff, maybe giving the patine that it deserves ;) Almost one long year
has gone by and sadly enough, there's no big new and flashy features to
show off. But, nevertheless,
Qsynth 0.3.5 is out from the closet!
Hope you enjoy the (not so big) news :) Have fun.
Description:
Qsynth is a FluidSynth GUI front-end application written in C++ around
the Qt4 toolkit using Qt Designer. FluidSynth is an excellent command
line software synthsizer based on the Soundfont specification.
Website:
http://qsynth.sourceforge.net
Project page:
http://sourceforge.net/projects/qsynth
Downloads:
- source tarball:
http://downloads.sourceforge.net/qsynth/qsynth-0.3.5.tar.gz
- source package (openSUSE 11.2):
http://downloads.sourceforge.net/qsynth/qsynth-0.3.5-2.rncbc.suse112.src.rpm
- binary packages (openSUSE 11.2):
http://downloads.sourceforge.net/qsynth/qsynth-0.3.5-2.rncbc.suse112.i586.r…http://downloads.sourceforge.net/qsynth/qsynth-0.3.5-2.rncbc.suse112.x86_64…
- binary packages (Ubuntu 9.10):
http://downloads.sourceforge.net/qsynth/qsynth_0.3.5-2.rncbc.ubuntu910_i386…http://downloads.sourceforge.net/qsynth/qsynth_0.3.5-2.rncbc.ubuntu910_amd6…
Change-log:
- Initial widget geometry and visibility persistence logic has been
slightly revised as much to avoid crash failures due to wrong main
widget hidden state.
- General source tree layout and build configuration change.
- Most modal message dialog boxes (eg. critical errors) are now replaced
by system tray icon bubble messages where available.
- Reverb and Chorus parameter ranges have been revised to match and
comply with fluidsynth back-end (libfluidsynth).
- Fluidsynth channel info and unset program interfaces are now in use
where available (libfluidsynth >= 1.1.1, EXPERIMENTAL).
- Global configuration state is now explicitly saved/committed to disk
when Options dialog changes are accepted and applied.
- Output peak level meters get their long deserved gradient look.
- Automatic crash-dump reports, debugger stack-traces (gdb),
back-traces, whatever, are being introduced as a brand new configure
option (--enable-stacktrace) and default enabled on debug build targets
(--enable-debug).
- Added Czech (cs) translation, contributed by Pavel Fric.
- The channel preset selector (Channels/Edit...) has been seriously
crippled for ages, only showing the presets of the last loaded
soundfont, now fixed.
- Minimum number of MIDI channels allowed on engine setup has been
dropped from the old value 16 to as low as 1 (one), not that it makes a
difference, as (lib)fluidsynth internals just rounds it to the nearest
multiple of 16 anyway.
- Cleanup to knobs source, simplified from redundant stuff.
Weblog (upstream support, yours truly):
http://www.rncbc.org
License:
Qsynth is free, open-source software, distributed under the terms of
the GNU General Public License (GPL) version 2 or later.
Cheers && Enjoy.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Mark Knecht wrote:
> On Thu, Apr 22, 2010 at 1:17 PM, Robin Gareus <robin(a)gareus.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi again,
>>
>> Since 6pm UTC today linuxaudio.org is hosted on a new server (actually a
>> VM).
>>
>> Due to slowly failing hardware on the old machine were urged to perform
>> the migration ahead of schedule and were unable to send out a
>> notification about it beforehand.
>>
>> The hosting is (still) provided by by the Virginia Tech, Department of
>> Music and Digital Interactive Sound & Intermedia Studio. Many thanks to
>> Ico Bukvic. Daniel James takes care of DNS. and a big thanks to
>> Marc-Olivier Barre who manages the email services.
>>
>> All systems go.
>> robin root
>>
>
> Aren't VM's cool?!
They certainly are cooler that calling Ico on a Sunday morning and
asking him to drive to campus and press the reset-button or sth. :)
but actually optimizing a virtual machine's I/O for >1 TB/month traffic
and sending ~1Million of [valid] emails per month is much harder than on
bare metal.
> The site works but not at the link above. That says under
> construction. Adding the www in front brings the main page right up.
> The links on the left work but none of the announcement links in the
> middle of the page are working for me at this time.
Thanks for reporting this. It's good to know there are people who keep
an eye open.
I hazard a guess that this occured because you did not flush your
browsers' DNS cache and/or you were unlucky to just try that while I was
tweaking some apache preferences.
Anyway, there may still be a few minor glitches as we continue to tweak
the system during the next days. - but don't hesitate to contact us
should you experience some unexpected behaviour with the site.
Cheers!
robin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi again,
Since 6pm UTC today linuxaudio.org is hosted on a new server (actually a
VM).
Due to slowly failing hardware on the old machine were urged to perform
the migration ahead of schedule and were unable to send out a
notification about it beforehand.
The hosting is (still) provided by by the Virginia Tech, Department of
Music and Digital Interactive Sound & Intermedia Studio. Many thanks to
Ico Bukvic. Daniel James takes care of DNS. and a big thanks to
Marc-Olivier Barre who manages the email services.
All systems go.
robin root
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkvQrr4ACgkQeVUk8U+VK0KmlQCfbNOpDl+xBSngTnxcd6ax/NDI
M3UAn3VWgwVKp6O57XnMLCDuCwo+QRgB
=lkZU
-----END PGP SIGNATURE-----
Dear mailing list users,
The list migration to the brand new virtual is complete and all the
problems seems to be fixed. As Robin told me when we were in the middle of
this panicky evening: "when we find what the problem is, we will all laugh
about it". Well, let me share the laughing with you:
It was just a typo !
Funny how trouble in the computer world eventually always turn out to be
an invisible typo in a configuration file :)
Enjoy your new server and post away !
Cheers,
--
Marc-Olivier Barre
XMPP ID : marco(a)marcochapeau.org
www.MarcOChapeau.org
Hi there,
I'm sorry to inform you that our email services are currently disrupted.
Due to increasing hardware problems with the linuxaudio.org server in
previous weeks we're already prepared a new machine. Another major outage
of linuxaudio.org this morning (UTC) forced us to switch to the new host
a bit early...
All services but for mailman (email-lists) are online and functional.
We're working on resolving the problem and will inform you about our
progress.
robin & marc-olivier
Drumstick is a C++ wrapper around the ALSA library sequencer interface using
Qt4 objects, idioms and style. ALSA sequencer provides software support for
MIDI technology on Linux. Complementary classes for SMF and WRK file
processing are also included. It is used in KMetronome, KMidimon
and KMid2, and was formerly known as "aseqmm".
Since the release 0.3.0 there are two libs: drumstick-alsa and drumstick-file.
Changes:
* Allow to build drumstick-file library under Windows.
* New method MidiClient::parseAddress() replacing the ALSA function
snd_seq_parse_address() in MidiPort::subscribeTo() and similar methods.
* Fixed MidiClient::getAvailableInputs() and getAvailableOutputs() forcing
to always retrieve the updated clients list from ALSA.
Copyright (C) 2009-2010, Pedro Lopez-Cabanillas
License: GPL v2 or later
Project web site
 http://sf.net/projects/drumstick
Online documentation
 http://drumstick.sourceforge.net/docs/
Downloads
 http://sourceforge.net/projects/drumstick/files/0.3.1/
openSUSE Build Service - RPM packages
 http://software.opensuse.org/search?baseproject=ALL&p=1&q=drumstick
Regards,
Pedro
Hello,
i want to grab some external sources (cdplayer) with jack. i run a jack
instance with 48000 Hz and it works perfectly with my cd player and ardour.
but if i take a cheaper cdplayer, the signal will only be came in with 44100,
because there seems no resample and sync between the master (soundcard) and
slave (cheapoCD) . so, the signal will always being played to slow. i found a
workaround with a small external box, which resamples the incoming signal
before it get into the soundcard.
Since a while, i think about a software solution, which puzzles me a bit. if i
doing the process without the external resampler, what must be done with the
signal.
If the original source is 44100 Hz, the incoming signal is 48000 (because of
jack). if i try to resample it, the current buffer get shorter, because the
signal need to be decreased.
How can a correct resampling process be done?
Thanks c~
Hi everyone,
got nothing to do during the Easter holidays ? I don't think so...
The second edition of ____The LAC Times____ is online:
http://lac.linuxaudio.org/2010/LAC_Times_2010_04_02.pdf
Subjects in this edition:
* A first glimpse of the LAC 2010 programme
* The 150-Years-of-Music-Technology Composition Competition
* A short history of recording sound [part 2]
No longer do you need to worry what to do at Easter. Now you'll worry what to do first:
study the programme to decide which day(s) you're gonna visit the Linux Audio Conference,
work on your composition or read Than's second history lesson.
Enjoy !
Marc
I'll put a printer-friendly version under the News tab of the LAC site soon.