libgig is a C++ cross-platform file loader library for Gigasampler and DLS
Level 1 and 2 files.
You can get the sources (including command line tools), API documentation, UML
diagram and a short kick start docu at:
http://stud.fh-heilbronn.de/~cschoene/projects/libgig/
Changes since libgig 0.6.0:
* general changes:
- various big endian specific corrections
(successfully tested now on PPC)
- minor adjustments to avoid compile errors on some systems
(using now pow() instead of powl() and --pedantic g++ compiler switch)
- libtoolized the library
- added man pages for the command line tools
(gigextract, gigdump, dlsdump, rifftree)
* src/gig.cpp, src/gig.h:
- fixed bug in decompression algorithm which caused it not to detect
the end of a stream
- added method GetVelocityAttenuation() to class 'DimensionRegion' which
takes the MIDI key velocity value as an argument and returns the
appropriate volume factor (0.0 ... 1.0) for the sample to be played
back, the velocity curve transformation functions used for this are
only an approximation so far
- fixed class attributes 'Sample::LoopStart', 'Sample::LoopEnd' and
'Sample::LoopSize' which reflected wrong values
- class attributes 'Sample::LoopStart' and 'Sample::LoopEnd' are now
measured in sample points instead of byte offset
- renamed misleading attribute name 'Sample::MIDIPitchFraction' to
'Sample::FineTune'
- added class attribute 'Sample::LoopSize'
- added method GetInstrument(uint index) to class 'File'
- added ReadAndLoop() method to class 'Sample' which is an extension to
the normal Read() method to honor the sample's looping information
while streaming from disk
- changed interface for 'attenuation_ctrl_t', 'eg1_ctrl_t' and
'eg2_ctrl_t': replaced this huge enumeration by a structure which
reflects the MIDI controller number in case of an ordinary control
change controller (this saves a huge switch-case block in the
application of the library user)
- renamed following attributes in class 'DimensionRegion':
'AttenuationContol' -> 'AttenuationController',
'InvertAttenuationControl' -> 'InvertAttenuationController',
'AttenuationControlTreshold' -> 'AttenuationControllerThreshold'
- minor fix in API documentation for method GetVelocityAttenuation() in
class 'DimensionRegion'
* src/RIFF.cpp, src/RIFF.h:
- added additional API documentation
- minor fix in Chunk::Read() method (only a minor efficiency issue)
* src/gigdump.cpp:
- added printout of samples' looping informations
Best regards
Christian Schoenebeck
Chris!
It looks like your other mailserver subscribes to the same blacklist.
I laughfed when most of Spain got blacklisted the other week, but beeing
in that situation is no fun at all :(
I hope that the good people at chello.se will soon solve the problem.
/jens
This is a quick report back from the LADSPA bird-of-a-feather session that
happened on Friday morning at the LA Conference. Attendees of the session
can expand on any details that aren't clear here once they recover :)
The atendees signed off on the text that has unanimous agreement, but not
on the open question IIRC.
Date 2004-04-30 10:00
Duration 3:30
Present 11 people (dont have a list of names, sorry)
Users 10
Plugin devels 3
Host devels 6
Unanimous agreement was reached on a number of pointsdditions, these are:
Momentary hint: additional hint (requires toggle) - indicates that control
(UI) shouldn't latch the control.
Port paths: '/' should be used as a port path component divider. No
leading slash will be used. This is for grouping related controls
in UIs and to allow more natural reflection of LADSPA port names
into OSC or HTTP, for example.
Zero pointer buffer values: if hint bit is set then the buffer pointer can
be NULL to indicate that the port is not connected.
There will be a LADSPA 2.0 which will differ from the 1.0 series only in
enforcing all metadata to be represented externally. No features over what
was agreed here will be added. Design work will start as soon as the
conference finishes. Estimates for time to completion are on the order of
2 months.
Open Questions
There is the possibility of an interrim 1.2 ladspa.h version that will add
the momentary hint, port paths, zero pointer buffer values and port name
extension enumerations, and will be deprecated by 2.0. It was decided to
leave it to the LADSPA devleoper community to vote if this was
desirable, as there was no consensus.
- Steve
Disposable Soft Synth Interface (DSSI, pronounced "dizzy") is a
proposal for a plugin API for software instruments (soft synths) with
user interfaces, permitting them to be hosted in-process by audio
applications. Think of it as LADSPA-for-instruments, or something
comparable to a simpler version of VSTi. It's intended to be simple,
easy to write plugins for, GUI-toolkit-agnostic, and slightly biased
towards familiarity with MIDI, and is proposed as an interim measure
until bigger and better things come along: hence "disposable".
The proposal consists of an RFC, which describes the background and
defines part of the proposed standard, plus a documented header file
(dssi.h) which defines the remainder. The distribution also contains
a handful of public-domain example files including an almost complete
(but not pretty) host implementation and a simple synth plugin with a
GUI. The API itself is licensed under the LGPL.
The full RFC may be read here:
http://dssi.sourceforge.net/RFC.txt
The header file is here:
http://dssi.sourceforge.net/dssi.h.txt
The 0.1 distribution containing RFC, header and examples may be
downloaded from SourceForge: see http://dssi.sourceforge.net/ and
http://sourceforge.net/project/showfiles.php?group_id=104230 .
This proposal was constructed by Steve Harris and Chris Cannam.
Comments to LAD please! (Steve will be at ZKM, as those of you who've
seen the schedule thingy will know; I can't make it there myself, so
I'd quite like to see some feedback here.)
Chris
Hi!
Apparently our mailsever has been blacklisted by all-day-breakfast ...
Damned script-kiddies :(
So, since this discussion is kind of relevant here, I try get the
message thru anyway. Sorry Chris!
On tor, 2004-04-29 at 16:11, Chris Cannam wrote:
> On Thursday 29 Apr 2004 2:19 pm, Jens M Andreasen wrote:
> > I think I will not be really, totally happy before I see something
> > like:
> >
> > void (*midi_msg)(LADSPA_Handle instance,
> > unsigned byte msg[4]);
>
> This would be exactly equivalent to the existing run_synth(), would it
> not?
Mmm .. This would replace, I think, all of your considerations on how to
extend LADSPA. It is (probably?) the only extension really needed. MIDI
is a very powerful protocol, and the beuty is that the client needs only
to implement those parts it needs to get going.
For a synthesizer one can ignore start, stop and pause as well as SMPTE,
but for a sequencer or arpeggiator timing would be the name of the game.
As a synthesizer developer I *could*, if I wished so, implement
running-status and thus discover that I have been disconnected, but it
is not required ...
mvh // Jens M andreasen
> Chris
>
Hi,
Have a play. Please. I know it might not be the most exciting app
in the world, but feedback would be good. This is the first time
I've written anything non-trivial in Linux.
The spectrum analyser is back, now as a toggleable X window.
Resizing to follow.
One annoying bug - when the SA window pops up, it steals focus. If
anyone knows how to create an unfocused window, preferably using only
xlib, or something else ubiquitous, please please tell me.
http://dis-dot-dat.net/code/sauditor/
James
Hi,
for those who can't get enough Linux Audio in their diet:
The Linux Audio Mini-Conf @ LCA2005 will be held before linux.conf.au,
Australia's national Linux conference, in April 2005 at the Australian
National University in Canberra, Australia.
More details, including the call for technical presentations and an
archive of the previous year's miniconf, is at:
http://www.metadecks.org/events/lca2005/
Conrad.
Hi,
TAP-plugins 0.5.0 released today, featuring:
* New plugin: TAP Dynamics,
a versatile tool for changing the dynamic content of your tracks.
Currently supports 15 dynamics transfer functions, among which there
are compressors, limiters, expanders and noise gates.
* Ardour (the recommended host for these plugins) now supports drop-down
lists in plugin GUIs, so there are no more long port labels.
* Minor fixes, improvements, new screenshots ;-)
Homepage: http://tap-plugins.sf.net
Enjoy,
Tom
sauditor is a simple, fast, sample auditor that outputs through jack
and has a curses interface.
http://dis-dot-dat.net/code/sauditor/
Changes:
It doesn't (or shouldn't) break anymore.
The spectrum analyser has been removed for now, until I get around to
writing a new one.
Doesn't show files/dirs starting with "." by default anymore - use the
-a option to turn them back on.
The brain-damaged directory traversal is fixed.
Plenty of tidying up done.
James
Hi, as you may know I'm the author of simsam (http://simsam.sf.net) and I'm
a little stuck with some typical audio application design problems.
So far I've been using an Observer pattern to have the GUI updated as soon as
a parameter changes. Thus any operation setting a parameter can trigger one
or several Widgets to be redrawn. Since so far I only set parameters from the
GUI thread, the resulting GUI updates also run in the GUI thread, so no problem
there.
One problem however is that access to the parameters isn't synchronized and
therefore concurrency problems exist. The same problem exists between MIDI and
audio thread, as MIDI events are currently handled entirely in the MIDI thread.
The obvious answer is to use mutexes to synchronize the parameters, but then
of course they aren't rt-safe.
The next obvious answer would be to use a lock free FIFO. I've seen some code
passing MIDI events to an audio thread that way. Thus the state is only
maintained in the audio thread. But what about GUI events? And GUI callbacks?
Surely one doesn't want the audio thread to execute widget redraws. So one has
to de-couple these mechanisms, for example by defining event and update
messages and passing those around by FIFOs instead of direct parameter
manipulation / direct GUI callbacks. Now this would totally break my app and I
would therefore like to hear some thoughts on the whole issue before I start
messing things up (even worse ;-P).
Thanks
Christian Henz