Hello, (I'm new to this list, so hi everyone!)
I'm rather stuck on the following: I'm writing an app that uses JACK for its
audio output. I now want to control this app using midi but I have trouble
figuring out how to synchronize the rendered sound to the incoming events.
The events, midi notes for example, come in with timestamps in one thread.
Another thread (the one entered by process()) renders the audio. In order to
render properly, it would need to calculate the exact sample at which the
incoming note should begin to take effect in the rendered output stream.
If you have an evenly spaced font, here's a graphical representation of the
problem:
|...e.....e|e....e....|...ee...e.|.....e.e.e|....e...e.| midi events
|..........|...rrr....|.rr.......|......rrr.|....rrrr..| rendering
|..........|..........|ssssssssss|ssssssssss|ssssssssss| sound
Here, the e's represent midi events (but could be gui events just as well).
The r's in the second bar represent the calls to the process function of my
app. During this time, the audio that will be played back during the next
cycle will be rendered. The s'es in the third bar represent the actual sound
as it was rendered during the previous block. The vertical bars represent
blocks of time equivalent to the buffer size.
The best I can think of now is that I have to record midi events during the
first block, process these into audio during the second block (because I
want to take into account all events that occured during the first block) so
it can be played back during the third. Now, all is fine, but time in the
event-bar is measured in seconds and fractions thereof, but time in the
third bar is measured in samples. How can I translate the time recorden in
the events (seconds) to time in samples? How can I know at which exact time
relative to the current playback time my process() method was called?
If I just measure time at the start of my application I'm afraid things will
drift. Is that correct? How have other people solved this problem? Hope
somebody can help!
Regards,
Denis
_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
The Generalized Music Plug-In Interface (GMPI) working group of the MIDI
Manufacturer's Association (MMA) is seeking the input of music and audio
software developers, to help define the technical requirements of GMPI.
The objective of the GMPI working group is to create a unified
cross-platform music plug-in interface. This new interface is hoped to
provide an alternative choice to the multitude of plug-in interfaces that
exist today. Among the many benefits of standardization are increased
choice for customers, lower cost for music plug-in vendors and a secure
future for valuable market-enabling technology.
Like MIDI, GMPI will be license free and royalty free.
Phase 1 of the GMPI working group's effort is to determine what is required
of GMPI: What sorts of capabilities are needed to support existing products
and customers? What are the emerging new directions that must be addressed?
Phase 1 is open to any music software developer and is not limited to MMA
members. It will last a minimum of three months, to be extended if deemed
necessary by the MMA. Discussions will be held on an email reflector, with
possible meetings at major industry gatherings such as AES, NAMM and Musik
Messe.
Following the collection of requirements in Phase 1, the members of the MMA
will meet to discuss and evaluate proposals, in accordance with existing MMA
procedures for developing standards. There will be one or more periods for
public comment prior to adoption by MMA members.
If you are a developer with a serious interest in the design of this
specification, and are not currently a member of the MMA, we urge you to
consider joining. Fees are not prohibitively high even for a small
commercial developer. Your fees will pay for administration, legal fees and
marketing. Please visit http://www.midi.org for more information about
membership.
To participate, please email gmpi-request(a)freelists.org with the word
"subscribe" in the subject line. Please also provide your name, company
name (if any) and a brief description of your personal or corporate domain
of interest. We look forward to hearing from you.
Sincerely,
Ron Kuper
GMPI Working Group Chair
I am looking for a good set of portable, supported atomic.h-style
primitives for userspace applications. I am not especially interested
in the low-level functions defined in <asm/atomic.h>. I really want
something more powerful like the kernel's compare_and_swap(),
cmpxchg(), test_and_set(), atomic_inc_and_return(), or fetch_and_add()
primitives. My intuition is that almost everything of interest could
be programmed out with a good compare_and_swap() or cmpxchg()
implementation.
These should work on most hardware platforms and operating systems, at
least as many as are possible and practical. They should work well
with both multithreaded UP and SMP. They need to work across multiple
process address spaces with shared memory. I would normally want to
avoid releasing different application binaries for UP and SMP.
They should be realtime-safe, which means that programming things out
using posix_spin_lock(), etc., is probably not good enough, except
perhaps as a generic solution to handle hard-to-support platforms.
While my needs are not unique to Linux audio, many audio applications
probably share them. So, I wonder what other people here on LAD are
doing.
All I've found so far are...
(*) kernel implementations of <asm/atomic.h> and <asm/system.h>.
These were written for kernel use, though some also work in
userspace. At least most platforms are probably fairly well
tested.
But, I prefer to avoid using kernel header files in application
code, mostly for portability and maintenance reasons.
Distributions handle them in non-standard ways, making it hard
to explain to users how to resolve the dependency. Also,
porting to non-Linux platforms becomes problematic.
(*) glibc seems to have a good set of functions internally
AFAICT, these are for the library's own use, not part of the
supported external interface. I'll investigate further.
(*) ardour has its own <pbd/atomic.h>
This does not seem to be well tested yet. But, a recent patch
by Robert Jordens at least makes it compile correctly on all the
Debian platforms using #ifdef's. Since the code was taken
directly from kernel sources, it is even likely to work on most
of those platforms (if compiled correctly).
(*) ardour has a ring queue implementation in ringbuffer.cc
There is also a C version included in the JACK example-clients
directory. These are excellent for some problems, but certainly
not for everything.
Advice or comments?
--
Jack O'Quin
Austin, Texas, USA
EL GORDO SWEEPSTAKE LOTTERY COMPANY S.L
PLAZA COLONE-28080
MADRID-SPAIN.
FROM: THE DESK OF THE MANAGING DIRECTOR INTERNATIONAL PROMOTIONS/PRICE AWARD DEPARTMENT.
REF N�: EGSL/25003127/CSL/02
BATCH N�: 0007571982
DEAR FRIEND,
RE: AWARD NOTIFICATION/ FINAL NOTICE.
We are pleased to inform you of the release of the results EL GORDO SPANISH SWEEPSTAKE LOTTERY/ INTERNATIONAL PROGRAM, Held 12THJuly 2003. Your name attached to a ticket number 025-1146992-750 with serial number 2113-05 drew the lucky numbers 4-18-24-30-31-35 which consequently won the lottery in the 3rd category. You have therefore been approved for a lump sum payout of 625,000.39 (Six hundred and twenty five thousand dollars and thirty-nine cents) in cash credited to the file reference number: EGSL/25003127/CSL/02. This is the from a total cash price of 5,368,770.00 (Five million three hundred and sixty-eight thousand, seven hundred and seventy dollars only) shared among the seventeen international winners in this category.
CONGRATULATIONS!!!
Your fund is now deposited with a Trust and Security Company insured to your name.
We advice that you keep this award from public notice until your claiming or unwarranted taking advantage of this program by participants. All participants were selected through a computer ballot system drawn from 25,000 names from Asia, Africa, Australia, Canada, U.S.A. ,New Zealand, Europe and North America as part of our international promotions program which we conduct once every year. We hope that with part of your prize, you will part-take in our end of year high stake $1,300,000,000.00 international lottery.
To begin your claim please contact your claim agent, Mr. William Lopez, foreign services manager, payment and release order department, Tel: +34 696 023 002, OR via Email: superstandard(a)terra.es for processing and remittance of your prize fund into your designated bank account.
Note: All prize funds must be claimed before the end of September 2003 after this date all funds will be returned to the MINISTERIO DE ECONOMIA Y HACIENDA as unclaimed. In order to avoid unnecessary delays and complications, please endeavour to quote your reference and batch numbers in every correspondence with us to your claim agent. Furthermore, should there be any change in your address do inform your claim agent as soon as possible. Congratulation once again from all members of our staff and thank you for being part of our promotion program.
N.B. Any breach of confidentiality on the part of the winners will result to disqualification. Please do not reply to this email address. Contact your claim agent.
Best regards
The Management.
From; Mr. Michael Makeh,
Banque Financiere De L'Afrique,
Lome-Togo.
My dear,
I wish this my proposal will not come to you as a surprise. I am Mr. Michael Makeh, with Banque Financier De L'Afrique with regional office in Lome-Togo. We had a foreign client (Mohamed Hussein Hanadi ), who deposited the sum of US$7.8 million (Seven Million Eight Hundred Thousand United States Dollars) with our bank. Unfortunately,this client was among the victims of EGYPTAIR FLIGHT NO.990 that crashed on the 31-10-1999 in the atlantic ocean, U.S.A. Confirmable from the website; ( www.cnn.com/us/9911/02/egyptair990.list/index.html ). But, since that year after the death of our client, we have not had anybody that comes for the claims of this money as the next of kin to our client. A situation I have monitored closely with my position in our bank.
Now, having monitored this deposit and managed it over the years before and after his death, and hence nobody has showed up as the next of kin for the past years now, I have removed the file to my "private vault". I now humbly solicit for your assistance in this issue. I wish to present you as the next of kin to this our client so as to claim out this money, before it is remmited into the fedral account where other people may aswell claim it directly without going to this lenght. I have taken every necessary precautionary measures concerning this issue and arrangement has been concluded by me in achieving this goal, provided you will follow my instructions in the process. I am only waiting for your response to enable me move the funds to your agreed safe account. This does not have any risk attached to it as all the internal documentations would be handled by me and every loop holes sealed also provided you give me your assistance and support.
I therefore request you to confirm your interest by a return message and I will furnish you with the full details and what to do concerning this deal. What you stand to gain would be discussed and it is negotiable before the deal commences.
Thank you in anticipation of your urgent response to my request stating your wish in this deal.
Kind regards,
Mr. Michael Makeh.
Hi.
I released ZynAddSubFX 1.4.3 at
http://zynaddsubfx.sourceforge.net
ZynAddSubFX is a free software synthsizer with many
features.
Paul.
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
I have done some testing on different audio codecs with different
settings.
Results are available at http://www.sonarnerd.net/projects/wavcomp/
More tests to come... Any comments on testing procedure are welcome.
Is someone able to put test .wav through ATRAC (back-and-forth)? I'd
like to include it in test results.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
1. A short summary of changes
A set of severe bugs in audio mixing code have been fixed.
Pyecasound build process has been improved. Reporting chainsetup
parsing errors has been improved significantly. Support for
the JACK 0.80 transport interface has been added. Support for
reading and writing aiff, snd and au files has been fixed.
Changes have been made to ensure correct operation with
the NPTL package recently added to Linux kernel and glibc.
A serious bug in metronome timing was fixed. Minor bugs
in dynamic sample rate changes, MIDI-server initialization
and the ewf file format have been fixed.
---
2. What is Ecasound?
Ecasound is a software package designed for multitrack audio
processing. It can be used for simple tasks like audio playback,
recording and format conversions, as well as for multitrack effect
processing, mixing, recording and signal recycling. Ecasound supports
a wide range of audio inputs, outputs and effect algorithms.
Effects and audio objects can be combined in various ways, and their
parameters can be controlled by operator objects like oscillators
and MIDI-CCs. A versatile console mode user-interface is included
in the package.
Ecasound is licensed under the GPL. The Ecasound Control Interface
(ECI) is licensed under the LGPL.
---
3. Changes since last release
* Support for JACK 0.80 transport interface. The recently
released JACK 0.80.0 marks another milestone for Linux audio
development. The new transport interface allows concurrent use
of multiple independent audio applications with full
sample-accurate transport synchronization. This release of
Ecasound provides full support for the new transport API.
See the following links to ecasound-list postings that
give examples of how to use Ecasound with the new transport API:
http://eca.cx/ecasound-list/2003/08/0005.htmlhttp://eca.cx/ecasound-list/2003/08/0070.html
* Metronome timing bug. There was a subtle bug in the
pulse gate operator that is used to generate the
metronome signal. This bug caused a small (<0.5%) timing
error in metronome speed. The bug has been fixed, but the
change in speed might cause problems for working with
sessions recorded with previous versions of Ecasound.
Thanks to Carsten Bauer for finding the bug.
Full list of changes is available at
<http://www.wakkanet.fi/~kaiv/ecasound/history.html>.
---
4. Interface and configuration file changes
Libecasound interface version number was incremented to 11.
This release is backwards compatible with interface
versions 9 and 10. See 'ecasound/libecasound/ChangeLog'
for a detailed list of changes.
Libkvutils interface version number was incremented to 6.
This release is backwards compatible with versions 5 and 4.
See 'ecasound/kvutils/ChangeLog' for a detailed list of changes.
Note! Using libecasound and libkvutils outside Ecasound has
been discouraged since the release of 2.2.0 in Jan 2003. The
interface changes introduced in this 2.3.0 release should
only affect a small group of distributors and developers.
Apps such as Ecamegapedal need to be recompiled only if
you want to take advantage of the new features introduced
in the latest Ecasound release.
---
5. Contributors
Patches - Accepted code, documentation and build system changes
Kai Vehmanen (various)
Bug Hunting - Reports that led to bugfixes (items closed)
Jeremy Hall (3) -- non-default chainsetup srates, mixdown
signal leak bug, pyecasound install
Junichi Uekawa (3) -- non-default chainsetup srates,
pyecasound install, gcc-3.3 verification
Janne Halttunen (2) -- locale-settings broke map-* commands,
MIDI-server startup bug
Vegard Lima (2) -- feedback bug, ewf srate bug
Carsten Bauer (1) -- timing bug in metronome and pulse gate
Ismail Donmez (1) -- build errors with sys-readline option
Lars Henrik Mai (1) -- aiff/au/snd bug
Stephan Niemz (1) -- non-default chainsetup srates
Al Oemens (1) -- reporting chainsetup parsing errors
Oliver Thuns (1) -- -ei big shift-x values
Tommi Uimonen (1) -- problems with ecasignalview channel meter
layout
---
6. Links and files
Web sites:
http://www.eca.cxhttp://www.eca.cx/ecasound
Source packages:
http://ecasound.seul.org/downloadhttp://ecasound.seul.org/download/ecasound-2.3.0.tar.gz
Distributions with maintained Ecasound support:
Agnula - http://www.agnula.org
Debian - http://packages.debian.org/unstable/sound/ecasound2.2.html
DeMuDi - http://www.demudi.org
FreeBSD - http://www.freebsd.org/ports/audio.html
Gentoo Linux - http://www.gentoo.org
PLD Linux - http://www.pld.org.pl
PlanetCCRMA - http://www-ccrma.stanford.edu/planetccrma/software
SuSE Linux - http://www.suse.de/en
Contrib Packages for Distributions:
Mandrake - http://rpm.nyvalls.se/
Slackware - http://www.audioslack.com
Various distros - http://apps.kde.com/rf/2/info/id/2146
Note! Distributors do not necessarily provide packages for
the very latest Ecasound version.
--
http://www.eca.cx
Audio software for Linux!
Firmware loaders for Midiman and Tascam USB MIDI devices
These packages allow you to use Midiman's MidiSport USB MIDI interfaces and
Tascam's USB Audio interfaces with Linux. These devices require a firmware
download before an operating system driver (e.g. ALSA's snd-usb-audio) can
access them.
These loaders use the same firmware used by the Windows drivers, so you need
a file of the respective Windows driver to install them. (See README files
for details.)
-*-
The MidiSport firmware loader is required to use USB MIDI devices from
M-Audio/Midiman under Linux. Release 0.1 contains some slight enhancements
to the installation process, and is the first release hosted on
SourceForge.net.
Supported devices:
MidiSport 1x1, 2x2, 4x4, 8x8, KeyStation, Oxygen, Radium, Uno, and maybe
MidiSport 2x4.
-*-
The Tascam firmware loader is required to use USB MIDI/Audio devices
from Tascam under Linux. There is also a loader for the FPGA
configuration data included. The firmware and the FPGA configuration
data will be extracted from your Windows driver files during
installation. This is an initial release.
Supported devices:
US-122, US-224 and US-428
-*-
To download the loaders, go to the project home page:
http://usb-midi-fw.sf.net/
martin
Hi,
Back in March it was suggested that some additional hints should be
added to LADSPA - there was some discussion, but nothing since. Here's
what I gathered from the archives:
/* Hint MOMENTARY indicates that that a control should behave like a
momentary switch, such as a reset or sync control.
LADSPA_HINT_MOMENTARY
may only be used in combination with LADSPA_HINT_TOGGLED.
*/
#define LADSPA_HINT_MOMENTARY 0x40
/* Hint RANDOMISABLE indicates that it's meaningful to randomise the
port
if the user hits a button. This is useful for the steps of control
sequencers, reverbs, and just about anything that's complex.
Randomising
a control should not result in anything too suprising happening to
the user (eg. sudden +100dB gain would be unpleasant). */
#define LADSPA_HINT_RANDOMISABLE 0x80
/* Hint OUTPUT_METER indicates that the value of output
control port is likely to be most meaningful to the user if
displayed as a meter. Can be combined with LADSPA_HINT_LOGARITHMIC
if the meter should use a log scale. (e.g. dB)
*/
#define LADSPA_HINT_OUTPUT_METER 0x??
/* Plugin Ports:
Plugins have `ports' that are inputs or outputs for audio or
data. Ports can communicate arrays of LADSPA_Data (for audio
or continuous control inputs/outputs) or single LADSPA_Data values
(for control input/outputs). This information is encapsulated in the
LADSPA_PortDescriptor type which is assembled by ORing individual
properties together.
Note that a port must be an input or an output port but not both
and that a port must be one of either control, audio or continuous.
*/
[...]
/* Property LADSPA_PORT_CONTINUOUS_CONTROL indicates that the port is
a control port with data supplied at audio rate. */
#define LADSPA_PORT_CONTINUOUS_CONTROL 0x10
-
Myk