Hi,
It's my understanding that on synth devices (eg fluidsynth, and the
memory on loaded soundcards), one selects a sound via MIDI
'program-change' events, and can select a bank via MIDI 'controller
change/bank-select-msb' events.
However, when I have fluidsynth loaded with more than one soundfont
file, how do i select sounds from different banks within different
soundfonts?
I've tried all different combinations of program-change,
controller-change/bank-select-msb and controller-change/bank-select-lsb,
but nothing seems to work.
Ditto, how do I achieve this via the ALSA Sequencer API? (I've already
asked on the ALSA list, but people side-stepped the question).
All help appreciated.
--
Cheers
David
hi erik,
i've got another strange issue with libnsdfile (1.0.10beta6 and
earlier).
it seems to be related to SFM_RDWR mode again. if i open an existing
(but empty) file in RDWR mode, then switch to UPDATE_HEADER_AUTO mode,
then write to the file, then try to seek to the end of the file in
order to write again: then the seek command will fail or misbehave.
when seeking to file-end, SEEK SET, it will fail with "Internal
psf_fseek() failed.", if seeking to 0, SEEK_END, it will just seek to
zero regardless of the number of frames in the file.
all this proceeds if not switching to UPDATE_HEADER_AUTO. though not
included in the test case, i got the same behavior when using
WRITE_HEADER_NOW after each write instead of UPDATE_HEADER_AUTO with
my "real-world" code.
this behavior seems to be independent from the sndfile format, but
just tested with WAV/16bit, AIFF/16bit, AIFF/float.
attached the "small test case", hope erik will like it again...
bests,
martin
I'm currently fishing around for a college senior project and was
wondering:
(1) if the Gibson MaGIC protocol has gotten anywhere in the past 2
years. I havn't seen much in the news about it.
(2) if it would be worth porting it to linux.
I think I read most of the posts on this list concerning magic. The
biggest problem seems to be implementing the network card itself; MaGIC
send 48v using standard power-over-ethernet (defined in 802.3). I'm
assuming my eepro100 will fry. Good. I can implement other hardware.
Granted, I don't have that much experience programming this kind of
stuff, but, well, for a fun final project, it might just be worth
learning.
BTW, if anyone out there has any other project suggestions for a musical
*NIX guy, they would be GREATLY appreciated!
Thank you very much!
-Michael Tewner
--
Michael Tewner <tewner(a)jct.ac.il>
The Jerusalem College of Technology
Hi,
there's a serious typo in my previous mail, please ignore it and read this
one. Sorry for the duplicate.
i'm currently investigating making LDrum a DSSI instrument. Therefore i made a
simple and nearly empty DSSI header to test it with the dssi_example_host.
I encountered some C++ problems but after putting the extern "C" stuff in
place, dssi_example_host recognizes and starts my empty instrument :)
So i went on and started including some LDrum headers... and that broke the
instrument :(
dssi_example_host no longer recognizes nor starts it.
After hours of digging i'm finally stuck, because of another C++ problem.
Here's what happens:
When I use my instrument code which is nearly empty and which does not include
any LDrum headers (that is: headers which include C++ code) everything works
fine.
By simply adding the following include:
#include <iostream>
the instrument is broken. It is no longer recognized. This only happens with
iostream. Other headers like string or vector work fine (since these are all
templates no library should be required, right?).
I used 'nm' to grep for unresolved symbols in my instrument .so and when
including iostream there are some strange ones popping up (ios_base).
Instrument plugin without '#include <iostream>'
> nm ldrumdssi.so | grep U
U __gxx_personality_v0
U calloc
U free
U malloc
>
Instrument plugin with '#include <iostream>'
> nm ldrumdssi.so | grep U
U _ZNSt8ios_base4InitC1Ev
U _ZNSt8ios_base4InitD1Ev
U __cxa_atexit
U __dso_handle
U __gxx_personality_v0
U calloc
U free
U malloc
>
Can anybody tell me what I'm missing?
Regards,
Peter Eschler
--
"Without music, life would _O_/ \_O_/ +----------------------+
be a mistake - I would / )) [] | Peter Eschler |
only believe in a god who \\ // | peschler(a)t-online.de |
knew how to dance." (Nietzsche) // \\ +----------------------+
Hi,
i'm currently investigating making LDrum a DSSI instrument. Therefore i made a
simple and nearly empty DSSI header to test it with the dssi_example_host.
I encountered some C++ problems but after putting the extern "C" stuff in
place, dssi_example_host recognizes and starts my empty instrument :)
So i went on and started including some LDrum headers... and that broke the
instrument :(
dssi_example_host no longer recognizes nor starts it.
After hours of digging i'm finally stuck, because of another C++ problem.
Here's what happens:
When I use my instrument code which is nearly empty and which does not include
any LDrum headers (that is: headers which include C++ code) everything works
fine.
By simply adding the following include:
#include <iostream>
the instrument is broken. It is no longer recognized. This only happens with
iostream. Other headers like string or vector work fine (since these are all
templates no library should be required, right?).
I used 'nm' to grep for unresolved symbols in my instrument .so and when
including iostream there are some strange ones popping up (ios_base).
Instrument plugin with '#include <iostream>'
> nm ldrumdssi.so | grep U
U __gxx_personality_v0
U calloc
U free
U malloc
>
Instrument plugin without '#include <iostream>'
> nm ldrumdssi.so | grep U
U _ZNSt8ios_base4InitC1Ev
U _ZNSt8ios_base4InitD1Ev
U __cxa_atexit
U __dso_handle
U __gxx_personality_v0
U calloc
U free
U malloc
>
Can anybody tell me what I'm missing?
Regards,
Peter Eschler
--
"Without music, life would _O_/ \_O_/ +----------------------+
be a mistake - I would / )) [] | Peter Eschler |
only believe in a god who \\ // | peschler(a)t-online.de |
knew how to dance." (Nietzsche) // \\ +----------------------+
Hi,
this might be old news already, but just in case...:
http://lwn.net/Articles/84566/
--cut--
The 2.6.6-mm1 tree includes, among many other things, patches which add
two new /proc/sys variables. They are:
/proc/sys/vm/hugetlb_shm_group
If this value is non-zero, it is interpreted as a group ID which
gives access to the the "huge pages" feature of the 2.6 VM.
/proc/sys/vm/mlock_group
This variable behaves similarly, but it controls access to the
mlock() system call (which locks memory into physical RAM) instead.
--cut--
And continues with comments from Andrew:
--cut--
The problem, it seems, is that there are no better solutions on the
horizon. Says Andrew Morton:
""Capabilities are broken and don't work. Nobody has a clue how to provide
the required services with SELinux and nobody has any code and we need the
feature *now* before vendors go shipping even more ghastly stuff. ""
--cut--
This suggests that there is a good chance that realtime-lsm could be
accepted to the mainline kernel tree, if submitted!
--
http://www.eca.cx
Audio software for Linux!
Hi all,
I have recently published my thesis about the "Design and Implementation of a
Commodity Audio System". It contains a lot of information around the development
of an audio system and therefore might be worth for some of you to have a look
at. The booklet is available for download at
http://www.ife.ee.ethz.ch/~men/phd.shtml
I will appreciate any feedback or comments...
Regards, Men
> Just found this nice and small lisp. It is used in festival speech
> synthesis system and named SIOD (Scheme in one defun)
Isn't that the one used in Gimp? It's similar to Guile, I think.
My apologies for not following the discussion closely, but if it's
lisp vs xml, I'd vote for lisp, and even promise to provide the
C side of the tie-in.
> > Hey, it's the official scripting language of the GNU system.. :)
> We don't have a scripting language problem, we have a metadata problem.
And Guile, in my opinion, would be a great choice for either problem;
I think it is presented as "an extension language" -- the scripting
business comes for free, and wasn't to the point anyway.
But XML seems to be everywhere -- so is Windows...
Welcome to the 0.9beta12 release of Ardour. We are now moving ever
closer to a 1.0 release. This release includes an incredible number of
changes and improvements since beta11. We expect some instabilities
compared to beta11 to remain - please test, collect debug traces,
etc. etc.
+++++ FIRST IMPORTANT NOTICE +++++
Although beta12 will load sessions created by earlier versions of
Ardour, if it is allowed to save a session at any time, that session
will immediately be INCOMPATIBLE WITH ALL PRIOR VERSIONS OF ARDOUR.
If you have important sessions, you are advised to back up the session
state files (generally called <session-name>/<session-name>.ardour).
I repeat: if you care about being able to use prior versions of Ardour
on your existing sessions, you MUST BACKUP YOUR SESSION STATE FILES.
Please rest assured that after 1.0 appears, no incompatibility,
forward or backwards, will be tolerated in any future version.
+++++ SECOND IMPORTANT NOTICE +++++
Why the change in the session files? At some point as work on beta12
was in progress, we realized that Ardour's panning model was
fundamentally broken. Not just the mathematics of the pan law, but the
actual software architecture of panning. Fixing this has required a
massive set of changes to Ardour's basic data flow and a lot of subtle
and not-so-subtle changes to a lot of code. On the plus side, we now
have a completely modular panning architecture that will make it
trivial, mostly, to use plugins for panning in the future.
++++++ THIRD IMPORTANT NOTICE ++++++
ardour/ksi is no longer built by default. The changes to libardour are
massive and widespread, and I do not have the resources to spend time
getting ardour/ksi to catch up with them. I will reenable default
building if and when ardour/ksi compiles again. I wish I could spend
time on this, but the work is just too much at a time when I
desperately need to get Ardour to a reasonable 1.0 release.
+++++ FOURTH IMPORTANT NOTICE +++++
This version of ardour will NOT compile with gcc 2.95. we are now
using the standard C++ class "stringstream", which has no support in
gcc2.95. i will accept patches that attempt to use the gcc class
"strstream", but i am not willing to spend time on this myself.
Changes since 0.9beta11
------------------------
A) PANNING
* panning control is per-stream
code is now supporting the notion of the "number of active
streams" within various parts of a signal processing
"route". this is different and orthogonal to the number of
inputs and outputs the route has. if you put a 1in/2out
plugin into a 1in/1out route (which arguably should not be
possible), then before the plugin there is 1 active stream,
and afterwards there are 2.
* panner linkage
- panners for all streams/channels can be moved
together or in opposing motion.
* new "bar controllers" for controlling panning to
a stereo output, 1 per data stream
* dbl-click on the bar controller to get numerical
entry, then Return or Tab to get back
to graphics.
B) AUTOMATION
----------
* gain and pan automation now totally separated
- you can playback pan automation while
doing touch automation on gain.
* if playing automation, and playhead goes past
the last control point, value remains
at that level.
* one button for gain automation state and one for
pan automation state per mixer strip
* ignore the automation mode for now
* touch automation for panning now works.
* hide all automation control points, display them
only as mouse pointer moves through them
* automation values reflected after transport stop
or locate if automation is not off, or when
automation is turned on.
C) PLUGIN GUIs
-----------
* use bar controllers (see Panning above) instead of sliders
D) OTHER MAJOR FUNCTIONALITY
-------------------
* initial support for win32/x86 VST plugins as native objects
in Ardour
* Added exclusive solo operation (ctrl-alt click on solo button)
which sets that track to be the only soloed track. it has a
momentary counterpart (ctrl-alt middle-click) which temporarily
exclusively solos the track while the mouse button is pressed.
BTW, middle-clicking mute buttons is momentary mute as well.
* Added seamless looping. this can be enabled in the options editor
(misc tab). why is this an option you ask? well, our current
looping scheme simply does a transport reposition at the end of the
loop, and while completely sample accurate, there can be a time gap
between the end of the loop and the beginning. This happens due to
the slow-sync jack transport system, to allow all clients to
reposition in sync (including ardour). However, if you need truly
seamless looping with no gap, you can enable this option which will do
it within ardour only -- you must disable ardour as the jack
transport/time master for it to work. In the near future, the Jack
transport system may acquire a notion of looping, and at that time,
seamless may be used at any time.
Note that for full compatibility with other transport aware apps, the
normal (non-seamless) looping with ardour as jack transport master is
required and is still quite usable, so don't be discouraged from using it.
* drag-n-drop from a file manager implemented for
placing audio files into audio tracks
* LADSPA Presets are now saved in RDF format in
~/.ladspa/rdf/ardour-presets.n3. Ardour will also
read any other RDF files saved in that location.
* region list redesigned
* mouse wheel events now scroll canvas, not change mouse mode
* always store to current snapshot file, do not make read-only
anymore (might cause problems on older sessions with
snapshots if editing the snapshot)
* mouse shuttle mode (the return of "scrub")
a new widget replaces the ffwd/rev buttons to provide
continuous speed control in forward and reverse directions.
* Added option to update actively recording regions with waveforms.
Much cooler than just the pink boxes, eh? On by default, you
can turn it back to the plain pink boxes from the display tab
of the options window.
B) MINOR IMPROVEMENTS + BUG FIXES
------------------------------
* correct handling of JACK transport API when transport master
* improved handling of SMPTE timecode
- SMPTE frames-per-second can be edited from the options editor
- SMPTE offset (what absolute time with respect to audio frame
zero is SMPTE 0:0:0:0) can be edited from the options
editor
- correct drop frame calculations
* fix for "Destroy Last Capture" bug, plus a correction for
a thinko that caused a segv if DLC done twice between
captures.
* recent session dialog doesn't have "subtrees" for sessions
with just a single state (snapshot)
* xfade editor changes
- "shade under line"
- fix left offset of wave display
* buttons/arrows on editor vertical scrollbar now work
* template selector hidden in new session dialog if the user
has no templates
* fix problem with exporting caused by JACK transport fixes
* MMC buttton relabelled "External MIDI Control", and moved
to MIDI tab of Options editor, along with "Send MMC"
* Better implemented the momentary mute and solo operations so that
the previous state is restored on mouse-release.
* added "lock", "unlock", "normalize", "reverse" to region context
menu
* add new operation to return captured regions to their "captured"
location (does not work for embedded/imported regions). the
operation is in the region context menu as "Original position".
* fixes for region naming when handling external audio files
* redesign new session dialog to use a tabbed notebook
* make sure option editor's "follow playhead" button is in-sync
with follow playhead setting
* fix long-standing bug with MIDI request pool running out of
memory.
* fix export of 100% zeroes in 32 bit integer sample files
* added MMC command when in master MMC mode for transport
startup (Deferred Play)
* correct design flaw in creating regions from session file.
(fixes some odd behaviour when undoing close to
start of working on a session, because regions did
not have the correct history set up)
* limited shuttle speed when mouse departs the control box.
* keep JACK shutdown/kick message on top of editor window
* use "e" and "p" to position edit/playhead wherever mouse is
* fixes for transport button madness
* fix for autoloop indicator region visibility
* made the horizontal scrollbar be a standard one
* included new fader pixmaps from ryan (precursor to new theme)
* ExportDialog saves Track information. It doesn't restore it yet though.
* LRDF enumerations are displayed in a combo box in the PluginUI.
* Updated gtk-ardour Russian translation and added new libardour Russian translation.
* Recent Sessions dialog doesn't display sessions that have been deleted.
* Trying to sample a file in the AudioLibrary that has been moved or deleted won't crash.
* fix catastrophic, stupid, unbelievable and just plain ridiculous
bug in editor constructor that left edit_cursor and
playhead_cursor with random values when Editor::set_state()
was called.
* move "optimization flags" setting into a global autoconf file,
and call AM_OPT_FLAGS from most configure scripts
* increase size of UI request pool
* increase size of UI request ringbuffer
* finally get all tracks connected to ins+outs
when using "auto-connect" options.
(previously only the first N tracks
would be connected, where N was the
number of physical i/o's on
your audio interface)
* prevent GTK from loading its default
RC files at all costs.
* fix gcc 3.3 "bug" in libsoundtouch
* start to use the new BarController widget in plugin GUIs
* fixed the declick on transport stop. yes, it probably never
worked, which is why you heard clicks on stopping. this also
fixes the problem where plugins are interrupted briefly on stop...
now reverb tails are undisturbed on transport stop.
* Audition port names are looked up at runtime.
* Library UI uses the new jftw in libpbd.
* The plugin selector is now sortable by clicking on the different column
titles.
* "stop at session end" option is now saved
* "splash/about window" design changes - unfinished, and wow is it
ugly. but its also more flexible, and i'll finish it RSN.
* several dialog windows forced to float over the editor
* "wait for loading" message removed
* when adding multiple tracks, GUI runs between each track
(causes ugly flashing of mixer window, however)
* Select context menu now contains
"Select all in track"
"Select all"
"Invert in track"
"Invert all"
(invert is known not to work on automation tracks)
* incorrect handling of stereo streams through routes fixed.
* check for adequate version of JACK
* fix recursive call to DiskStream::set_name() that caused a crash
when renaming a track
* fix PortInsert to do a pure wire-level copy - no gain, no pan
* count cycles for plugins
* make sends meter correctly
* clean up (longstanding) late initialization of several variables
(thanks valgrind!)
* convert error log to popup messages, mostly
* run Gtk::Main event loop while embedding/linking an external file
(and use the "watch/wait" cursor too)
* add a half-working detent for panner bar controllers
* try to improve operation of gain/pan automation buttons
* Added spanish translation. Thank you Alex Krohn.
* change pan line colors
* fix display of slide/splice mode
* clicks on track canvas views do not select track
* pack IO CLists in IOSelector in a scrolled window (needs theme name)
* select next IO port after making connection to current one
(speeds and smooths UI interaction when doing IO setup)
* Added spanish translation of ardour.1.
* test plugin configuration and display a dialog if its incorrect
(even when loading ... work in progress)
* Added russian translation of man page.
* Added valgrind shortcut for ardour into gtk_ardour. (arval).
* correct problem with lack of playback in rec-enabled
tracks when not using s/w monitoring
* apply gain to s/w monitored rec-enabled tracks
* fix nasty thread synchronization bug related to
allocation+use of session-wide pan automation
buffers
* provide (not very good) warning if rec-enable attempt
made on a track with no input connections
* more tooltips
* pan muting via context menu
* fix potential segfault in ::~Session caused by
double delete of playlists
* MIDI control for panning added back (untested)
hi *,
i've got a strange issue with libsndfile.
in foo (http://foo.sf.net) the SFM_RDWR mode is used, because target
soundfiles are created independently of the write process before, then
the file gets opened with SFM_RDWR to determine the target soundfile's
parameters (samplerate, channels...).
with SF_FORMAT_AIFF | SF_FORMAT_FLOAT (and SF_FORMAT_DOUBLE, btw., 2
channels) i notice a strange behavior: directly after creating the
file (without sf_writing anything) the number of frames of the file is
4 (SF_FORMAT_DOUBLE: 2 frames). this doesn't happen neither with the
SF_FORMAT_PCM_* things, nor with SF_FORMAT_WAV. with just 1 channel
the values are 6 resp. 3.
when reopening the file for writing (SFM_RDWR mode), there is no
difference between seeking to (0, SEEK_SET) and (0, SEEK_END), both
seek to 0. surprisingly, seeking to (4, SEEK_SET) doesn't return an
error.
after writing 512 frames after seeking (in all three cases) and having
closed the file, the number of frames is now 511 (1022 with 1
channel).
am i missing something, or is this a bug in libsndfile? attached my
test prog.
bests,
martin
