[linux-audio-dev] Vamp audio analysis plugin API 1.0 released
Vamp Plugin API and SDK 1.0 released The Centre for Digital Music at Queen Mary, University of London are happy to announce the 1.0 release of the Vamp Plugin API and software developers kit. http://www.vamp-plugins.org/ Vamp is a plugin API for audio analysis and feature extraction plugins written in C or C++. Its SDK features an easy-to-use set of C++ classes for plugin and host developers, a reference host implementation, example plugins, and documentation. It is supported across Linux, OS/X and Windows. The Vamp plugin API is also used by the Sonic Visualiser audio visualisation and analysis application. http://www.sonicvisualiser.org/ The development of the Vamp plugin API and Sonic Visualiser was partially supported by the SIMAC project (http://www.semanticaudio.org/) and the EASAIER project (http://www.easaier.org/), with assistance from CHARM (http://www.charm.rhul.ac.uk/). Chris
Re: [linux-audio-dev] ANNOUNCE: Sonic Visualiser and Vamp plugin SDK 1.0pre3 released
On Tuesday 20 Mar 2007 00:41, Paul Winkler wrote: On Mon, Mar 19, 2007 at 11:28:40PM +, Chris Cannam wrote: Sonic Visualiser is an application for viewing and analysing the contents of music audio files. It contains advanced waveform and spectrogram viewers, as well as editors for many sorts of audio annotations. What does annotations mean in this context? That's a good question. In principle it means pretty much any observation about the contents or context of the audio. Common examples relevant to the current Sonic Visualiser might be the locations of beats and bar lines in a performance with rubato; the extents of a particular structural segment of the music (the chorus, for example); textual labels such as lyrics or comments about the music; or symbolic note information like MIDI that is associated with a particular feature in the audio. SV handles all of those tolerably well, and has unusually good support for mingling user annotations with machine-generated annotations from plugins like beat trackers. It doesn't currently handle contextual metadata not associated with particular moments in the audio, like biographical information, collection tags like genre etc which can also be considered annotations. As one example of why anyone would be interested in annotating bits of an audio file by hand, have a look at the musicological tutorial from the CHARM project at http://www.charm.rhul.ac.uk/content/svtraining/analysing_recordings.html (This tutorial uses SV 0.9, and some of the things it does would be simpler with the 1.0pre version.) You can also use SV for little jobs like beat slicing (run a beat detection plugin, click-select beats, export as audio), practising your Chinese tones by comparing the spectral shape of your voice with the guys on ChinesePod, slowing down and looping non-contiguous bits of audio to compare one riff with another version later in the song, etc. Chris
Re: [linux-audio-dev] ANNOUNCE: Sonic Visualiser and Vamp plugin SDK 1.0pre3 released
On Tuesday 20 Mar 2007 21:05, Stefan Kost wrote: the screenshots look nice so I treid to build it. Could you maybe look into fixing the warnings the compiler gives for version 1.0. For me the build fails here: [...] ./base/TempDirectory.h:44: error: extra qualification ‘TempDirectory::DirectoryCreationFailed::’ on member [...] ./plugin/RealTimePluginInstance.h:84: error: invalid covariant return type for ‘virtual QString RealTimePluginInstance::getIdentifier() const’ /usr/include/vamp-sdk/PluginBase.h:81: error: overriding ‘virtual std::string Vamp::PluginBase::getIdentifier() const’ What exactly are you trying to build here? The code that causes these errors is not in Sonic Visualiser 1.0pre3. It looks as if you're trying to build an older Sonic Visualiser together with the newer Vamp plugin SDK. The downloads page is not very clear on this point (I hope to find time to tidy it up tomorrow), but the Source code download at the bottom is for the older 0.9 version, not the current 1.0pre3 (which is available on the SourceForge downloads page). Chris
[linux-audio-dev] ANNOUNCE: Sonic Visualiser and Vamp plugin SDK 1.0pre3 released
Announcing the release of Sonic Visualiser 1.0pre3, a pre-release for the soon forthcoming Sonic Visualiser 1.0. http://www.sonicvisualiser.org/ Sonic Visualiser is an application for viewing and analysing the contents of music audio files. It contains advanced waveform and spectrogram viewers, as well as editors for many sorts of audio annotations. Besides visualisation, it can make and play selections based on the locations of automatically detected features, seamlessly loop playback of single or multiple noncontiguous regions, synthesise annotations for playback, and time-stretch playback while retaining display synchronisation. Sonic Visualiser also makes use of the Vamp plugin API, for plugins that extract descriptive or analytical data from audio. Vamp is an easy to use plugin API with a comprehensive and well-commented SDK, and is now frozen for the Vamp 1.0 release. Sonic Visualiser is Free Software distributed under the GNU General Public License. The 0.9 release is available now in source code form or as binaries for Linux, OS/X, and Windows. For more information and downloads, please see http://www.sonicvisualiser.org/ For more information about Vamp plugins, please see http://www.sonicvisualiser.org/vamp.html See also the SourceForge page for this project at http://www.sourceforge.net/projects/sv1/ Sonic Visualiser was developed at the Centre for Digital Music, Queen Mary, University of London and partially funded by the European Commission through the SIMAC project IST-FP6-507142 and the EASAIER project IST-FP6-033902. Chris
Re: [linux-audio-dev] distros: don't package hexter 0.6.0
a configuration option Build configuration, or DSSI configure() ? The latter would fix it, while (it seems?) the former would mean distros having to choose between better sound and project compatibility on behalf of their users, which is not much of a choice. If you do mean the latter, then your previous fix seems better - a user can always choose to downgrade, or a packager find creative ways to provide both. I suppose a packager could include libraries built both with and without the option... but that's a compatibility minefield (with other ad-hoc packages from other distros). Hoping you did mean DSSI configure, Chris
Re: [linux-audio-dev] audiogui
On Monday 26 Feb 2007 23:40, Leonard Ritter wrote: radial is for weirdos with the motor skills of a clockmaker. Correct! But where have all the radial supporters gone? There were enough to sustain quite a flamewar about this a couple of years back. I prefer linear in both axes (right or up to increment, left or down to decrement), so there may be some scope for disagreement after all. I've been considering making a small library of Qt4 widgets based on the ones in the current SVN of Sonic Visualiser -- dial (based on the RG/qsynth one), thumbwheel, panner, fader (based on Hydrogen). They aren't particularly beautiful or consistent to look at -- if they were, I wouldn't just be considering it, I'd have bundled them up a while ago. But what they do do is work consistently: click and drag to adjust, without any inadvertant jumps on plain clicks; double-click to open a text field edit window provided by the widget; middle-click or ctrl+left-click to reset to default; mouse wheel supported. They all (except panner) support attaching a mapper object that translates between the underlying floating point values and screen integers, so you can use them for things like logarithmic scales and get the correct mapping and units for their automatic tooltips and the edit window. Chris
Re: [linux-audio-dev] audiogui
On Tuesday 27 Feb 2007 17:22, Thorsten Wilms wrote: Looked at Ardour 2 recently? Yes. I like the new fader/meter. Chris
Re: [linux-audio-dev] audiogui
On Monday 26 Feb 2007 12:41, Leonard Ritter wrote: (i dare you to start an audio ui design war with me). Radial or linear mouse control for the dials? Chris ducks and runs for cover
Re: [linux-audio-dev] LADSPA needs wishes
On Monday 29 Jan 2007 07:39, Nedko Arnaudov wrote: Chris Cannam [EMAIL PROTECTED] writes: What are they? Do they do anything else, besides host LV2 plugins? I'm aware of these LV2 hosts: * jack_host from libslv2 project, by Dave Robillard * elven from ll-plugins project, by Lars Luthman * zynjacku, by me * maybe ingen (om), by Dave Robillard, LV2 support is ready too Thanks. Is there any more information about Elven (besides the code)? Is Zynjacku specific to Zyn in any way, or is it just named that way because you wanted an LV2 host when you happened to be working on Zyn-based plugins? What else you want them to do? (zynjacku feature list is still open) Oh, I don't mind. I was just wondering. I suppose I was also wondering if any previously-existing applications besides Om/Ingen had started adding LV2 support yet. It's evident from my and Robert's posts in this thread that Rosegarden and MusE haven't, but there are plenty of others that might have. What about Dino? P.S. Antisocial humans don't read mailing lists. Yeah, they do. Me for example. Sorry for being so grumpy. Chris
Re: [linux-audio-dev] LADSPA needs wishes
On Saturday 27 Jan 2007 18:57, Nedko Arnaudov wrote: Robert Jonsson [EMAIL PROTECTED] writes: On Saturday 27 January 2007 06:47, Loki Davison wrote: why are you coding new stuff for a depreciated system? Why not LV2? And why should you code for a plugin standard that nothing supports? [...] nothing? i'm aware of 3 hosts that can host lv2 plugins. What are they? Do they do anything else, besides host LV2 plugins? There does seem to be a habit here for people to describe things as deprecated, when what they mean is they don't like them very much themselves, they no longer consider them state of the art, and there's a technically better alternative that isn't widely supported yet. (The ALSA sequencer API is another current example.) It's an arrogant and antisocial habit. For someone who wants to write effects plugins for a reasonably large audience of Linux users to use right now, there's one choice: LADSPA. DSSI has been a technically better choice for a few years now, but it has few hosts and I'm not sure whether all of those even support DSSI plugins as effects -- although they should. LV2 is also a technically better choice, but even less widely supported so far. That will change, but it's far too soon to be suggesting it's the only Linux plugin API worth writing for, especially as porting from LADSPA to LV2 (and/or supporting both) should be easy enough. You can argue for driving adoption of LV2 by writing cool plugins for it, but that's quite different from saying you shouldn't be writing for LADSPA at all. Chris
Re: [linux-audio-user] Re: [linux-audio-dev] LAD/LAU/LAA/Consortium/...
On Wednesday 17 Jan 2007 07:05, Predrag Viceic wrote: Rosegarden has a forum: http://www.nabble.com/RoseGarden-f2887.html FWIW Rosegarden doesn't have a forum -- the above is a web gateway to its user mailing list. It's OK for reading, but not much cop for posting. Chris
Re: [linux-audio-dev] LADSPA_Data audio values
On Thursday 21 Dec 2006 21:19, Iain Young wrote: Now..here's where Im confused. I thought the values for audio samples in LADSPA were -1.0f...1.0f (with -1.0f being infinity). The range is a voltage range. It's -1.0 to +1.0 where 0.0 is effectively -Inf dB, -1.0 is 0dB at negative voltage and +1.0 is 0dB at positive voltage. Digital silence is all zeroes, not all -1.0s. Though inputs coming from hardware will be low level noise rather than absolute silence. Chris
Re: [linux-audio-dev] plugin loaders
On Thursday 21 Dec 2006 02:12, Paul Davis wrote: /usr/local/lib64/ladspa:/usr/local/lib/ladspa:/usr/lib64/ladspa:/usr /lib/ladspa:/Library/Audio/Plug-Ins/LADSPA; } Shouldn't you also have $HOME/Library/Audio/Plug-Ins/LADSPA or some such on OS/X? Chris IANA OS/X developer
Re: [linux-audio-dev] about MIDI timing...
Clemens: Most sound cards don't have an internal timer that could be used for MIDI timing. ALSA uses whatever timer is configured, the default for this is the RTC timer. It is? For ALSA sequencer queues? I thought the default was system timer. Maybe it just depends on the modules you have loaded. My impression from Rosegarden users' reports has been that trying to use the ALSA sequencer with the RTC timer (something I've never bothered with myself: I always use a 1000Hz system timer) is a reliable way to lock up your system completely, with most kernels from about 2.6.13 or so onwards. I've been meaning to investigate with the latest ALSA source and at least make a decent bug report for ages, but you know the way it is, there are only sixty hours in the day. It would be wonderful if some excellent person had fixed it in the meantime. Chris
Re: [linux-audio-dev] about MIDI timing...
Lee: This is/was a bug or multiple bugs in the kernel's RTC driver. It started to appear around 2.6.13 because that was the kernel release where they regressed the default timer granularity from 1ms to 2.5ms, forcing apps like Rosegarden to switch to RTC based timing. No, it genuinely went from working to broken - it's not a case of always being broken but never previously being necessary. It broke first in RT kernels, so I'm guessing it broke in mainline with an RT patch merge. I'm not aware of anyone these days successfully using Rosegarden with snd-rtctimer - if anyone out there is, do say so. Either you get a 1000Hz kernel or you suffer with crap timing. Clemens: Kernels = 2.6.15 work. The most recent such report we had was from a user of OpenSUSE 10.1 (with 2.6.16 I think?). I suggested trying an ALSA driver upgrade; apparently it didn't help. The thread should be easily found in the Rosegarden list archives by searching for rtc and opensuse. I don't have a computer here to test it on at all myself at the moment, I'm afraid. I will do later. Honest. Chris
Re: [linux-audio-dev] about MIDI timing...
Me: I'm not aware of anyone these days successfully using Rosegarden with snd-rtctimer - if anyone out there is, do say so. To test: * start RG (version 1.0 or newer) * go to Settings - Configure Rosegarden - Sequencer - Synchronisation * change the sequencer timing source option to RTC * close configuration window, press play. It probably doesn't matter whether you have a file loaded or not. Success - play pointer moves smoothly Failure - system locks up solid, reboot required. If it does lock up, you may need to edit your rosegardenrc to restore the timer setting before you can run RG again. Chris
Re: [linux-audio-dev] about MIDI timing...
Me: No, it genuinely went from working to broken And actually, I think my recollection is wrong. I think it probably broke in 2.6.8-rt, and in mainline in either 2.6.9 or 2.6.10. Before that it worked fine, but we always used the system timer instead for RG because it seemed simpler (it was always 1000Hz then) and we stuck with that as the default and I guess rather abandoned the RTC option. Sorry for being so lax. If it does work now, then of course, that's great. Chris
Re: [linux-audio-dev] light C++ set for WAV
On Wednesday 26 Jul 2006 11:12, Florian Paul Schmidt wrote: Well, it is very thin though. Which is not a bad thing at all. One could make ue of an arbitrary amount of more advanced C++ features if desired though (i.e. templates parametrized with the type you want to read for example, or operator and operator for reading and writing, etc.) operator and ... ugh. Secondly, with regard to the method names, which do you prefer: - OpenRead - openRead - open_read vote++, i never cared for the more java style methodName convention. I think if your class is named LikeThis, then your method should be named likeThat (Java-style). If your method is named like_this, then your class should be named like_that (STL-style). Either is fine, but don't mix your dialects. Since you're the only person who actually responded to the real meat of my email, I have to assume that you are the only person on this list with a love for C++ and hence the only one who should have any real input on this issue ;-). Nicely worded :) Mmm. For what it's worth, I write mostly C++ but have no problem with using the libsndfile C API. I don't really mind whether it has a C++ API as well or not. So yes, you probably should ignore me. Chris
Re: [linux-audio-dev] Basic MIDI question
On Wednesday 26 Jul 2006 13:06, Alfons Adriaensen wrote: I don't have a midi spec at hand here. Do you mean running status is shared by all channels and not per channel ? This would make it less than trivial to combine or split midi streams. The channel is part of the status byte. Chris
[linux-audio-dev] ANNOUNCE: Rosegarden 1.2.4 released
ROSEGARDEN 1.2.4 RELEASED Miscellaneous locations -- Bastille day, 2006 The Rosegarden team are pleased to announce the release of version 1.2.4 of Rosegarden, an audio and MIDI sequencer and musical notation editor for Linux. http://www.rosegardenmusic.com/ The 1.2.4 release addresses several issues with the prior 1.2.3 feature release. 1.2.4 introduces no new application features. Fixes in this release include, briefly: * Avoid crash on startup if /dev/snd/seq does not exist * Fix incorrect sequencer status report (no driver) * Fix MIDI Text Marker export * Fix text encoding for Lilypond 2.6 (UTF8 instead of ISO-8859-1) * Fix stuck notes in matrix after pressing a stop button * Fix crash when erasing a duplicated key signature * Fix crash when switching documents with a tempo editor window open * Fix incorrect sorting and insertion logic in marker editor * Fix hang in main canvas when a segment has zero duration * Fix audio preview display for repeating audio segments * Update percussion matrix when a different drum mapping is selected * Avoid crash when deleting a device with percussion matrix open * Fix matrix display for notes outside range of current key mapping * Ensure correct segment is acted on when clicking overlapping segments * Fix sequencer crash when playing back tiny audio files * Avoid display hang when too many segments overlap * Fix several build system bugs, and compilation with gcc-4.1.2 This release also includes several new MIDI device definition (.rgd) files, as well as updates for Catalan, Russian, Swedish, Czech and Italian translations, and a completely new Finnish translation from Heikki Johannes Junes. Special thanks go to Pedro Lopez-Cabanillas for preparing the release. For more information about Rosegarden and what it can do for you, please see http://www.rosegardenmusic.com/ Rosegarden is Free Software under the GNU General Public License.
Re: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis
On Tuesday 23 May 2006 10:45, Asbjørn Sæbø wrote: ERROR: AudioJACKTarget: Failed to connect to JACK server Are you running the static build from the download page, or did you build SV yourself? The static build has libjack 0.100 statically linked. If your version of jackd is incompatible with the linked version, it will fall back to ALSA via PortAudio (which presumably fails because JACK is using the soundcard). So, if you're using this build, which version of jackd do you have? Chris
Re: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis
On Tuesday 23 May 2006 11:49, Stéphane Letz wrote: Why do you do a static with libjack? I was thinking jack was supposed to always be used with a shared lib version... Well, what is the proper solution when distributing a binary? 1. Link libjack statically 2. Omit JACK support Just linking dynamically isn't an option. I want to fall back on another output if JACK is absent, not fail to start at all. I suppose there may be 3. dlopen libjack from within the program and continue if it fails I haven't tried that; is it a reasonable option? Chris
Re: [linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis
On Tuesday 23 May 2006 11:20, Asbjørn Sæbø wrote: But of course, I probably do not have port-audio installed. That shouldn't matter -- it's linked statically... Chris
[linux-audio-dev] [ANN] Sonic Visualiser: An application for audio visualisation and analysis
Announcing Sonic Visualiser, an application for viewing and analysing the contents of music audio files. http://www.sonicvisualiser.org/ Sonic Visualiser contains advanced waveform and spectrogram viewers, as well as editors for many sorts of audio annotations. Besides visualisation, it can make and play selections based on the locations of automatically detected features, seamlessly loop playback of single or multiple noncontiguous regions, synthesise annotations for playback, and slow down playback while retaining display synchronisation. Sonic Visualiser also introduces the Vamp plugin API, for plugins that extract descriptive or analytical data from audio. Vamp plugins for onset, pitch and note detection using the Aubio library are available, as well as plugins for tempo tracking, chromagram analysis, constant-Q spectrogram, spectral centroid, power curve and tonal change detection. There is also a comprehensive SDK for use by developers of Vamp plugins and hosts. Sonic Visualiser is Free Software distributed under the GNU General Public License. The 0.9 release is available now in source code form or as binaries for Linux, OS/X, and Windows. For more information and downloads, please see http://www.sonicvisualiser.org/ For more information about Vamp plugins, please see http://www.sonicvisualiser.org/vamp.html See also the SourceForge page for this project at http://www.sourceforge.net/projects/sv1/ Sonic Visualiser was developed at the Centre for Digital Music, Queen Mary, University of London and partially funded by the European Commission through the SIMAC project IST-FP6-507142. Chris
Re: [linux-audio-dev] Todays changes to LADSPA2 strawman
On Sunday 30 Apr 2006 00:01, Dave Robillard wrote: We need a better API with which to build good, useful things. So what are those things, and how will LADSPA2 get us to them? I'm not looking for perfect foresight here, just some inspiring examples. Just because one API is easier to extend than another, doesn't mean that it will necessarily happen easily or in a useful way (i.e. with consistent enough coverage from hosts or plugins to be really useful). The logarithmic hint discussion here is an example of that -- it's just about the most trivial thing that can be imagined as an application of an extensible API, yet it's ended up in a lengthy discussion with no consensus so far. Chris
Re: [linux-audio-dev] Todays changes to LADSPA2 strawman
On Saturday 29 Apr 2006 17:42, Dave Robillard wrote: On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote: The things that aren't obvious how to do are 1) the configure() callback OSC message. And there you've introduced something I haven't seen in this thread yet: sending messages rather than just values to your plugin. How come there are dozens of posts here talking about the name of the API and bitching over whether this extensible plugin API should start out with a logarithmic port hint, when things like this are going unmentioned? Is the expectation that any plugin be able to define that a certain port accepts any given structure of data, defined entirely in the RDF? Or what? 2) the dynamic program lists and midi mappings (static definitions could be written in the RDF file, but that's no fun) That's a tougher one. 3) program selection OSC message. You see that's all terribly glib, but the things that make the non-GUI parts of DSSI complex are not so much about how data is passed to and from the plugin as when it is passed, what the dependencies between things are (e.g. when you change a configure value, the programs may change; when you change a program, the ports may change), what the threading requirements are and so on. An entirely generic anything-in anything-out plugin is unlikely to be much actual use, in practice. 4) the run_multiple*() callbacks (how many plugins use these?) Hexter, Xsynth, WhySynth etc. run_multiple is DSSI's equivalent of MIDI channels. There is no channel information in the note messages passed to a plugin; instead the host creates as many instances as it needs, effectively one instance per channel, and run_multiple allows the plugin to share work between them if appropriate. If it has no work to share, it just doesn't bother providing this function. This can have advantages for the plugin (the simple case is simpler) and user (any plugin appears able to receive any number of channels of input, without the user's having to know what the plugin's actual configuration is). The main disadvantage is simply that it's different from how other MIDI-based APIs work. In my view it's better in isolation -- in a homogenous environment -- but can become awkward when mixed with actual MIDI devices. Chris
Re: [linux-audio-dev] RDF for CAPS plugins
Paul Winkler: OTOH, it's pretty obvious why this is the case. Imagine if it *did* have to resolve to something. What would that mean? That's a slightly perplexing detail even with the situation as it is. What if the URI *does* resolve as a URL? Would a host that looked up the URL and did something with the results (doesn't matter what, but let's imagine that the host defines the thing it will do and does it consistently) be committing a fundamental error? Chris
Re: [linux-audio-dev] Best opensource license to use?
i intend to release an application, which allows to use VST(i)s running on an XP machine from a linux jack client, hooked up over ethernet. If all the code is your own, consider the approach we used in dssi-vst, which is to use the GPL plus an exception to allow for the unavailability of VSTSDK sources. It won't be GPL-compatible or Debian free, but nothing will be if not all the source is available, and I think it best expresses the intention -- if your preference would naturally be for the GPL, that is. Meanwhile, write and remind Steinberg that their license could be more helpful to developers of Windows and Linux plugins and hosts. It won't be news and there's no real reason they should care, but it's worth a nudge that these things matter to people, including those who would like to promote, recommend and use their standard. As it happens I'm also shortly about to release a Windows plugin host that is not at all in competition with Steinberg products, but that can't host VSTs for licensing reasons and will use DSSI plugins instead. Hosting audio plugins is not a major part of this program so the difference isn't going to be all that significant to me or anyone else, but it's an interesting situation. Chris
Re: [linux-audio-dev] Errors trying to build dssi-vst 0.4 ... any help?
dssi-vst-server.cpp: undefined reference to `pthread_mutex_trylock' Does the file (I don't have it to hand and am not at a proper computer) have #include pthread.h at the top? If not, what if you add it? It may just be that another header includes this on other systems, but not on yours. Chris
Re: [linux-audio-dev] Errors trying to build dssi-vst 0.4 ... anyhelp?
i'm not sure which file you mean? i tried adding it to the top of dssi-vst-server.cpp, but that didn't work ... is that the one you meant? Yes, but I realise I was misreading the error (it was from the linker, not the compiler). How about an extra -lpthread in LDFLAGS or whatever in the Makefile? Chris
Re: [linux-audio-dev] Juce now has ALSA support!
On Wednesday 01 Mar 2006 19:03, Lee Revell wrote: Actually I think Julian has a point - I can't find the doc anywhere that says you output to the front speakers by opening the front device and rear the rear device, that apps should open the default PCM by default, that hw:x should only be used for special cases where direct hardware access is requires (like JACK), etc. Only half a dozen people in the world know these things. And here you are leaking them onto a public mailing list! Chris
Re: [linux-audio-dev] Free Software vs. Open Source: Where do *you* stand?
On Tuesday 21 Feb 2006 22:30, Dave Robillard wrote: On Tue, 2006-21-02 at 20:36 +, Chris Cannam wrote: On Tuesday 21 Feb 2006 20:12, Dave Robillard wrote: On Tue, 2006-21-02 at 15:05 +, Chris Cannam wrote: If my free software work puts a company or its developers out of work, then that's a problem for my conscience. It's not a victory for free software. Yes it is. No, the fact of people having been put out of work is not itself a victory for anyone. Straw man. I never said it was an overall win, just a win for free software. Right, and I said it wasn't. That's what you replied to. No straw man. Note though that I'm specifically talking about the failure of the proprietary company, not the success or popularity or quality of the free software alternative -- those good things, sure, celebrate them. It is subjective though, I admit. You could believe anything from every time a proprietary software company goes out of business for any reason, that's a victory for free software down. You can naturally argue that its being a victory doesn't depend on whether the people who caused it think that it is. But for my part, I think there is only victory if you think you're participating in competition. What's interesting is that I used this line of argument to explain my preference for free software over open source (because I think the term emphasises the positive, constructive and human nature of the work rather than an irrelevant businesslike cost/benefit angle) but the people arguing against me also appear to be on the free software side. Anyway, I've said more than enough. Chris
Re: [linux-audio-dev] Free Software vs. Open Source: Where do *you* stand?
Free software. But I do loosely use both terms. The problem with open-source-as-ideology is that it uses ends and evaluative methods drawn from business and applies them to things that are not business. It may or may not be true that open source development can produce better software for the consumer, but I don't think that that end is a sufficient one for people who are working from choice, for their own enjoyment on inessential software. If you find yourself working for no material return on things that are driven by goals best expressed in business terms -- to beat Microsoft, to produce a free alternative to product X, to get all the users and pull the carpet out from under Y -- then you've been seduced into doing work that is properly someone else's, or only properly done for money, or properly not done at all. The right answer to I want to use FL Studio really is use FL Studio. Until you can engineer a means by which FL Studio itself can become free software and its developers still eat -- or unless you can justify competing with it for business reasons -- it's foolish to get worked up about competing with it at all. That's a business end, and you're not in business. An irony of both open source and free software is that they make it easy to forget that all software is almost always written by decent humans -- for example, by implying that proprietary software developers are less moral and so less significant. If my free software work puts a company or its developers out of work, then that's a problem for my conscience. It's not a victory for free software. And it's not just business, because it's not business. I will have damaged people's livelihoods, for fun. WHAT is your FAVORITE ALBUM? Love's Secret Domain. Chris
Re: [linux-audio-dev] Free Software vs. Open Source: Where do *you* stand?
Tuesday 21 Feb 2006 15:30, David Kastrup wrote: Following your kind of logic, people caring for peace on Earth are damaging the livelihoods of weapon producers, decent people mostly, and that merely for their selfish desire of a world worth living in. *sigh* We're not talking about weapons. We're talking specifically about interesting and constructive pieces of music software. I believe that the existence of FL Studio and software like it enhances the world. You might argue that it would be better if written or distributed in a different way, but if you're arguing that this software would be better not existing at all -- as you might do of weapons -- then we have no common basis for this discussion. Write free music software if you wish to. I do. But if you're only doing it because you're sour about someone else's work, then you're not doing a good thing; don't delude yourself that you are. If their livelihoods get tougher because of a world where work is shared and exchanged between consenting and cooperating humans, so much the better. Read that again, and tell me whether it really says what you meant. Chris
Re: [linux-audio-dev] Free Software vs. Open Source: Where do *you* stand?
On Tuesday 21 Feb 2006 15:57, Pete Bessman wrote: On Tue, 2006-02-21 at 16:30 +0100, David Kastrup wrote: Following your kind of logic, people caring for peace on Earth are damaging the livelihoods of weapon producers, decent people mostly, and that merely for their selfish desire of a world worth living in. No, this is a bunch of BS. It's not bullshit. It's just misdirection. If you take out the subjective language, David just said: Following your kind of logic, people who oppose the proliferation of weapons are damaging the livelihoods of weapon producers, decent people mostly, because of their desire for a world without weapons. (Assuming for the benefit of his logic that you do think weapons producers are mostly decent as individuals and that their opponents may succeed in damaging their livelihoods.) Look closely at this. What do you see? The statement is true. It's not even controversial. But it doesn't add anything, because it isn't reasonable to suppose that we will have the same response to the fates of weapons producers as of authors of quality music software, nor to the ends of their opponents. It's only there to make you jump to a conclusion about one thing based on your emotional response to another. It's logical, but it's brainless. In any case, my point was that you shouldn't have to be making this sort of calculus. If it's not business, do it out of love, not because a business would do it. Chris
Re: [linux-audio-dev] Free Software vs. Open Source: Where do *you* stand?
On Tuesday 21 Feb 2006 20:04, Peter Bessman wrote: You're right, I jumped the gun. Arf. I'm wondering why it was brought up. Perhaps the assumption was made that we're all in the same boat on this subject --- clearly, such is not the case. Well, I strongly disagree with you on it -- but let's not go into that. I think you're probably right about the expectation. Chris
Re: [linux-audio-dev] Free Software vs. Open Source: Where do *you* stand?
On Tuesday 21 Feb 2006 20:12, Dave Robillard wrote: On Tue, 2006-21-02 at 15:05 +, Chris Cannam wrote: If my free software work puts a company or its developers out of work, then that's a problem for my conscience. It's not a victory for free software. Yes it is. No, the fact of people having been put out of work is not itself a victory for anyone. The world of Free Software (basically the public domain for the sake of argument) has been improved, and the world of computer users in general is better off. Sure -- you'd certainly hope that good things are also a consequence of the work, and they go on the other side of the ledger. If someone loses their job because their product was replaced with a superior alternative, well... this is how markets are _supposed_ to work. I'm not in the market. I'm not competing. Because I'm not competing, someone else's failure is not a success for me. Chris
[linux-audio-dev] ANNOUNCE: Rosegarden-4 1.2.3 released
The Rosegarden team are delighted to announce the release of version 1.2.3 of Rosegarden 4, an audio and MIDI sequencer and musical notation editor for Linux. Rosegarden is among the largest and most insanely ambitious Linux music software projects, and is the only Linux application to offer full composition and recording capabilities to musicians who prefer to use classical notation. http://www.rosegardenmusic.com/ The long-awaited 1.2.3 release of Rosegarden-4 offers a variety of new features, bug fixes and enhancements. These include: * The main segment canvas has been rewritten and is now faster, more responsive, more accurate, and marginally prettier than before. (This work proved much more complex than hoped, and accounts for much of the time spent since the 1.0 release a year ago.) * A new percussion matrix editor has been added. MIDI devices can have user-configurable percussion key maps, stored in the same device files as bank and program definitions. Users are invited to contribute their own. * Multi-track audio recording and simultaneous recording of audio and MIDI are now supported. * A project packager has been introduced and integrated, facilitating the exchange of complete Rosegarden projects including associated audio data and any other required files. * The Lilypond export function has been updated for Lilypond 2.6 and features a new Preview mode. * You can now control Rosegarden's mixer and other twiddly bits using an external MIDI controller device such as the Behringer BCF2000. * Rosegarden is now capable of synchronising to MIDI Time Code in master and slave modes (thanks to Vince Negri). MMC master and slave are also now supported. * Rosegarden's ALSA MIDI ports can now be connected and controlled using an external ALSA connection manager such as qjackctl (thanks to Pedro Lopez-Cabanillas). * The default sequencer timer selection should be better behaved than in 1.0 (eliminating the dreaded Rosegarden only plays the first note problem). * Effects plugins can now be applied to groups of audio instruments at the buss stage. * Many new icons and improved versions of old icons have been added (thanks to Vladimir Savic). * The build system now uses scons instead of autotools. This release also sees hundreds of bug fixes, including fixes to some long-standing issues with DSSI plugin support, JACK transport synchronisation, and punch-in recording. For more information about Rosegarden and what it can do for you, please see http://www.rosegardenmusic.com/ Rosegarden is Free Software under the GNU General Public License.
Re: [linux-audio-dev] Re: Programming Synth Knobs? [OT] UI issues
Loki Davison: What is wrong with just using jack-dssi-host? If you want a standalone version, you can just have a script, jack-dssi-host myplugin called myplugin for people to run. You don't even need that - just create a symbolic link from myplugin to jack-dssi-host. Chris
Re: [linux-audio-dev] xt2 coming to linux
On Friday 27 Jan 2006 14:03, Michael Bohle wrote: I don't like dssi-vst so much, too buggy Your bug reports and fixes have been invaluable. It dosn't work with fst 1.7 because of a graphical prob. I notice jacklab.net offers a binary distribution of libfst, and says an experimental version of ardour-fst is in preparation. How do you deal with the licensing problem? Chris
Re: [linux-audio-dev] xt2 coming to linux
On Friday 27 Jan 2006 14:57, Michael Bohle wrote: Sorry for this harsh words: dssi-vst needing very old wine for compiling and there is no development happens since long time. The bugs are mostly because of missing impelentations of some vst standards like sync to host or heavy freezes when activating any kind of midi learn within the vst. Fixes, including build fixes, are always welcome. So are specific examples of VST features that would be useful. Some VST features don't map well onto DSSI at all (e.g. I haven't yet thought of a good way of handling VST chunks: any ideas welcome) but others aren't there just because I haven't found the time to deal with them. But anyway, VST on Linux is dead now, beause most of the user are not able to compile it for themself. Thats pity, what can we do now? Distribute binaries of dssi-vst. That's one reason it exists in the first place. It won't solve all your problems, but it's better than nothing. Honestly, none of this is news. Even the jacklab.net site itself makes reference to the licensing problem... at the same time as ignoring it. Chris
Re: [linux-audio-dev] xt2 coming to linux
Lee Revell writes: On Fri, 2006-01-27 at 15:57 +0100, Michael Bohle wrote: But anyway, VST on Linux is dead now, beause most of the user are not able to compile it for themself. Wrong. You just need to write a wrapper that handles the compiling. Won't help if the code is to be part of a GPL'd application. Also, I think (?) you have to register to download the VSTSDK. Chris
Re: [linux-audio-dev] xt2 coming to linux
Lee Revell: Won't help if the code is to be part of a GPL'd application. The Linux kernel is a GPL'ed application yet Nvidia gets away with linking into it. Quite different. Anyone can distribute the kernel without caring about the existence of the nVidia drivers. But if an application includes the VSTSDK, it presumably isn't complete without it. Chris
Re: [linux-audio-dev] A sequencer example
On Sunday 15 Jan 2006 11:12, Florian Schmidt wrote: If you want to use alsa_seq's queues to schedule events for delivery at a later time, you probably might have a look at rosegarden. There's a file base/test/seq/generator.c in the Rosegarden source tree that does basically what was described using the sequencer queue. It does however schedule in real-time rather than beats (and so does Rosegarden itself). http://cvs.sourceforge.net/viewcvs.py/rosegarden/base/test/seq/generator.c?view=markup Chris
Re: [linux-audio-dev] Problem compiling with liblo: error: 'lo_address'does not name a type
Frank Barknecht: OSCServer.cpp:2: 'lo_address' is used as a type, but is not defined as a type. Wasn't lo_address called something else in very old versions of liblo? Maybe you have spare headers lying around. Or maybe I'm inventing things. Chris
Re: [linux-audio-dev] Audio/Midi system - RT prios..
Paul Davis: most of the ALSA sequencer's capabilities are redundant, which is compounded because it currently has no way of providing sufficiently accurate scheduling You say this as if it were self-evident, when it's been the subject of much of this thread. _Does_ it have no way of providing sufficiently accurate scheduling? If not, why not? This would imply that there is in fact no way for a userspace application on a normal Linux distribution to provide MIDI timing accurate enough to be perceived as correct in all circumstances. Chris
Re: [linux-audio-dev] Audio/Midi system - RT prios..
Paul Davis: i guess it all depends on one's definition of sufficient. my take is that there are several MIDI h/w boxes that guarantee MIDI delivery to a resolution that matches the wire protocol (1/3msec). until we have scheduling capabilities that match this (or better), i don't feel comfortable calling them sufficient. Ah, I see. I've no argument with that, but it isn't quite what I thought you were referring to. Chris
Re: [linux-audio-dev] Audio/Midi system - RT prios..
Florian Schmidt writes: I further assume that the alsa seq event system is used This is true of Rosegarden, and midi events are not queued for future delivery but always delivered immediately. but this isn't -- Rosegarden always queues events from a non-RT thread and lets the ALSA sequencer kernel layer deliver them. (Thru events are delivered directly, with potential additional latency because of the lower priority used for the MIDI thread.) In principle this should mean that only the priority of the receiving synth's MIDI thread is significant for the timing of sequenced events. We also have a mechanism to compensate for gradual drift between the MIDI timing source (kernel timers or RTC) and soundcard clock, when synchronising to audio, by adjusting the sequencer skew factor. (This happens to be similar to the mechanism for slaving to MTC, which is handy.) In my experience this is all a long way from foolproof. The most common problems for users seem to be: - ALSA sequencer uses kernel timers by default and of course they only run at 100 or 250Hz in many kernels. - ALSA sequencer can sync to RTC, but the associated module (snd-rtctimer) appears to hang some kernels solid when loaded or used. I don't have much information about that, but I can probably find out some more. - ALSA sequencer can sync to a soundcard clock, but this induces jitter when used with JACK and has caused confusion for users who find themselves inadvertently sync'd to an unused soundcard (the classic first note plays, then nothing symptom). The biggest advantage of course is not having to run an RT MIDI timing thread. My impression is that this aspect of MusE (which does that, I think) causes as many configuration problems for its users as using ALSA sequencer queue timers does for Rosegarden's. Any more thoughts on this? Chris
Re: [linux-audio-dev] Audio/Midi system - RT prios..
Florian Schmidt writes: Here's example output with rosegarden producing a supposedly steady stream of 16th notes at 120 bpm: [...] Those results certainly are pretty poor. We do have a very similar test in the Rosegarden tree (the complainer test) but it doesn't stress the system quite the way it seems your program does. I'll have to review the sequencer API and look at adding a separate RT MIDI thread as an alternative (which should be straightforward enough). The rationale for using queued events is simple -- ALSA provides the service, why duplicate it? -- but it's probably true that we've already spent far more time working around problems with it than we saved by not duplicating it. (Does anyone else use queued sequencer events in earnest?) Chris
Re: [linux-audio-dev] Audio/Midi system - RT prios..
Florian Schmidt: Yeah, i got a nice and juicy BUG in it (see below). So this is what kills rosegarden regularly here when run with RTC timing source. That'll be the chap. Mind you, I never saw the RTC- based timer measure significantly better than the system timer at 1000Hz. Although your measurements may vary, and it seems, probably would. Chris
Re: [linux-audio-dev] Audio/Midi system - RT prios..
Me: I'll have to review the sequencer API and look at adding a separate RT MIDI thread as an alternative Actually no, hang on a minute. First I want to know more about why the ALSA sequencer queue doesn't work better here. It's all very well saying it's irrelevant now that it's so easy to create RT threads, but I think that's bogus. Probably a substantial majority of Rosegarden users doing MIDI only are using systems on which it isn't possible for a random user to create RT threads at all. For these users, the ALSA sequencer ought to be able to do a lot better than an ordinary unprivileged thread can. I'd like to know why it might not. I'm not at a proper computer just now, to delve through code - anyone have any more idea about this? Chris
Re: [linux-audio-dev] Audio/Midi system - RT prios..
Paul Davis: frank (v.d.p) had the right idea back when he started this Huh? Started what? Chris
Re: [linux-audio-dev] Re: applying RIAA curves in software
On Saturday 29 Oct 2005 19:11, Paul Davis wrote: i have a music hall turntable, and it is the paragon of great design (glass platter!), reasonable cost and sweet sound. i have the mmf-5 with a goldring cartridge, feeding a NAD phono preamp. i am not sure what the availability is in europe, but they are made in the czech republic so ... I think these are basically the same thing as the Pro-ject turntables, highly regarded, nice to look at, and widely available in Europe (and also relatively cheap and made in the Czech republic). http://www.project-audio.com/en/turntables.html I use an ancient Thorens TD-150 I picked up on eBay. It's a bit battered, but a lovely turntable. Also a Goldring cartridge (a 1042). I do still buy records, mostly second-hand classical recordings. Chris
Re: [linux-audio-dev] Re: applying RIAA curves in software
On Saturday 29 Oct 2005 22:04, Jussi Laako wrote: I've transferred number of vinyls to CD using this equipment with very good results. Wish there were open source or even Linux software for authoring DVD-Audio discs to take full advantage of capabilities of vinyl hardware... Do you really think you can tell the difference between an LP and the same LP transferred to CD? (Assuming a decent CD player, and decent hardware used to do the transfer.) I have some pretty good equipment to hand, but much as I love the sound of LPs, I honestly can't tell the difference between LP originals and CDs burned from them. (I mix and match the two fairly freely, so I'm quite confident about that.) As far as I'm concerned, the attractive sound of LPs is a fortuitous accident of distortion rather than any particular enhanced capability of the hardware. Chris
Re: [linux-audio-dev] [ANN] WhySynth DSSI softsynth
On Sunday 09 Oct 2005 15:59, Lars Luthman wrote: jack-dssi-host whysynth.so Simpler still, start with this (or make the synth's installer do this): # ln -s jack-dssi-host /usr/bin/whysynth Then you can just run $ whysynth for the same thing (a standalone GUI program with ALSA sequencer MIDI input and JACK audio output). Chris
Re: [linux-audio-dev] Parameter feedback in Rosegarden (and elsewhere)
Jens: I have noticed that the midi-mixing-console in Rosegarden is not listening to external events (like knobs on your fancy midi-controller) It does in the current CVS version, and that in Studio to Go! 1.50. You have to connect your controller to the external controllers ALSA port, though. However, I wouldn't recommend the code for this to anyone - it's a brutal hack on a design not intended for this - so I can't add much to your initial point... Chris
Re: [linux-audio-dev] LilyPond version 2.6 available - Music Notationfor Everyone.
Albert Graef writes: that's great news. Certainly is! Has Rosegarden been updated to a newer Lily yet? Last time I looked, they were still generating 2.0 code. :( Rosegarden's been able to generate 2.2 code for ages, and 2.4 for a while - though I can't quite remember whether that was in the 1.0 release or not. We're partly but not completely up to date with 2.6. I might well look at that this week, unless anyone else offers. Our Lilypond output is not terribly well structured for any version, so a bit of an overhaul might be nice too. Chris
Re: [linux-audio-dev] jack_convolve-0.0.10, libconvolve-0.0.3 released
On Monday 27 Jun 2005 15:49, Florian Schmidt wrote: There are some problems with wrapping partitioned convolution into a ladspa/dssi. One of them is that ladspa/dssi do not garantee a chunk size in which the processing needs to be done. [...] So, the partition/chunk size is determined in the initialization phase and all processing later on happens in chunks of this size. Well, you could always suggest for DSSI to include a mechanism by which a plugin indicates that it must have a fixed block size. Most hosts could probably accommodate that, if they had to. You'd be in good company -- or at least, in company. dssi-vst, for example, will get audibly perturbed if the block size changes as it makes absolutely no attempt to buffer between the DSSI variable block size and the VST fixed one. At the moment this is an obvious bug in dssi-vst, but it could become a perfectly sensible feature with just a little tweak to the API... After a discussion with Mario Lang i think i will OSC'ify jack_convolve though and make the qt gui only an OSC controller for jack_convolve. It does seem a shame not to end up with a DSSI plugin as well, then, given that it would then have much the same structure already. Chris
Re: [linux-audio-dev] jack_convolve-0.0.10, libconvolve-0.0.3 released
Florian Schmidt: P.S.: I am also currently working on a qt app which uses libconvolve Any interest in making a DSSI plugin? Chris
Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
On Friday 17 Jun 2005 14:24, Alfons Adriaensen wrote: A few days ago I kicked up Rosegarden again to see if it could be useful for the project I was starting. It wasn't so I terminated it, only to find out later that there were still a number of KDE applications running, including a sound daemon, blocking access to all others. Grrr. I can sympathise with that. Rosegarden itself doesn't use or want the KDE sound daemon, so it's rather counterproductive that KDE likes to start it anyway. Chris
Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time toomany
Jan Depner: I was under the impression that there was bounds checking going on with vectors. Is this not the case? Nope. Chris
Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time toomany
On Thursday 09 Jun 2005 20:07, stefan kersten wrote:
On Thu, Jun 09, 2005 at 09:39:21PM +0300, Jussi Laako wrote:
On Thu, 2005-06-09 at 18:14 +0200, stefan kersten wrote:
int access(std::vectorint v, int i)
At least you are making copy here, should be
int access(std::vectorint v, int i)
actually not, structs are passed by reference.
$ cat a.cpp
#include cassert
struct A {
A() { }
A(const A ) { assert(0); }
};
void f(A) { }
int main(int argc, char **argv)
{
A a;
f(a);
}
$ gcc -O3 a.cpp -o a
$ ./a
a: a.cpp:5: A::A(const A): Assertion `0' failed.
Aborted
$
Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time toomany
On Thursday 09 Jun 2005 23:16, fons adriaensen wrote:
int access(int *v, int i)
{
return v[i];
}
Of course, passing that pointer by value is horribly inefficient.
int access(int *const v, int i)
{
return v[i];
}
Chris
Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
On Wednesday 08 Jun 2005 21:45, [EMAIL PROTECTED] wrote: then processing speed becomes extremely important. There have been some very good points made in this discussion and I will definitely investigate some of them. My problem here is that I've heard the same type of thing from companies and universities for way too long. Well, that's the thing. Most of the people in this discussion are saying true things, and the context is the reason they don't agree. I write in C++ these days and I particularly like the capability Paul mentioned of switching containers after the fact. But I've also worked on high-volume hydrographic and borehole data (although not as high volume as you're talking about) and much of the best and fastest software I worked on was in FORTRAN. It was well structured and well commented, and it was very readable and perfectly good code. Chris
Re: [linux-audio-dev] [ot] [rant] gcc, you let me down one time too many
On Wednesday 08 Jun 2005 21:35, Jussi Laako wrote: You can derive a new class from the template and overload the [] operator to perform exactly same as in C. After compilation the result is the same no matter if the template or C array is used. Are you sure this is still true in the gcc world, after they changed vector from an array to a real class in gcc 3.3 or whenever it was? Chris
Re: [linux-audio-dev] LADSPA Issues
On Wednesday 18 May 2005 09:56, Dave Robillard wrote: So why wasn't the unique ID the thing to use? Because it's impossible to find any way to guarantee it's actually unique, for example in the case of a wrapper plugin that generates plugins on the fly. ladspa-vst / dssi-vst are obvious real-world examples. (DSSI deprecates the LADSPA unique ID for this reason -- there are a few paragraphs about it in the current DSSI RFC.) And of course having to have a central body to issue IDs is painful: that's why most identification schemes these days use texts drawn from a pre-existing common pool, such as URIs for schema IDs. Many (possibly most) LADSPA hosts actually do use the unique ID to identify plugins. They will break badly when faced with generated plugins like these. The right thing to do is just make sure the .so name doesn't change. After all, other dynamic libraries are always referred to by .so name and nobody ever complains about that -- would you expect a packager to get away with renaming libxml.so to libextensiblemarkuplanguage.so without breaking anything? It's not seen as a problem for plugins on other platforms, either. There are still potential complications if a plugin library is installed more than once, but at least the user can be aware of them -- whereas a changing or conflicting unique ID might be impossible for the user to work around (or even to know about). And at least the problem (for the admin) of managing plugin libraries becomes the same as managing any other sort of library, rather than having to manage potential conflicts of IDs buried deep within the binary. Chris
Re: [linux-audio-dev] Waveform
On Monday 09 May 2005 21:19, Fisher, Michael R wrote: Hi, I'm extremely new to audio programming. I have a million questions, but the one burning my brain now is how do I get a program written with the qt widget library to display an audio waveform. You could look at the trivial_sampler example plugin in the DSSI plugin API distribution. That's a pretty simple bit of code that does (IMHO) tolerable waveforms in a Qt window. The only problem is it's not standalone so you'd need the plugin host as well. http://dssi.sf.net/ Download it and have a look at examples/trivial_sampler_qt_gui.cpp. It's the plugin in the front of the screenshot here: http://dssi.sourceforge.net/plong.png The black in the waveforms shows peaks, the grey averages. And trivial_sampler is public domain, so it's legal to do anything you want with the code. It's even legal to pretend you wrote it. Not that anyone will believe you for long, after this discussion. Chris
Re: [linux-audio-dev] Waveform
On Monday 09 May 2005 22:22, Paul Davis wrote: Hi, I'm extremely new to audio programming. I have a million questions, but the one burning my brain now is how do I get a program written with the qt widget library to display an audio waveform. this is massively harder than you think, assuming you want to (a) do it correctly and (b) offer zooming. Fortunately, if you don't care about doing it correctly or offering zooming, it's quite simple. Chris
Re: [linux-audio-user] Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
On Saturday 16 Apr 2005 01:00, [EMAIL PROTECTED] wrote: but it will stay like it is: i will tell the FSF if i find binarys of xfst ! Why would the FSF care? It's not as if xfst can be GPL. If it was, then people would be able to distribute binaries. It would be misleading at best to distribute software under a licence that offers rights that you know no user can legally exercise. Chris
Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
On Tuesday 12 Apr 2005 02:18, Paul Davis wrote: The VST-per-server implementation might not, but there's no very compelling reason not to have multiple VSTs in a single server serving multiple clients. That would be less reliable than a dssi-vst type service can be, but no less reliable than fst, and it should scale nearly as well. It's been on my todo list for ages... i still don't think that scales. the cache might still be warm, since the server is repeatedly invoked, but its still 2 context switches per-plugin invocation DSSI has a mechanism for coalescing these (which is what I was thinking of) but of course it's for synths only, and makes no sense (in the host) for effects. Chris
Re: [linux-audio-user] Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
On Tuesday 12 Apr 2005 02:16, Paul Davis wrote: Ah. No point talking about it here then. this is LA*D*, where we are free to ramble about every stillborn idea that shows up in our wacky little minds, isn't it? :) Except it's a bit of a pointless ramble if nobody reading you knows what you're talking about. Talking about code on a free software mailing list without the code being available to the list's readers seems a bit futile. You can't legally link anything that uses the Steinberg headers into a GPL application and distribute the results as a binary, with or without source. well, actually, thats not quite true. *I* can do that for Ardour, and I suspect that the Rosegarden group could do that for RG as well. Ditto Werner with MusE; since we are the copyright owners, we can do whatever we damn well please :) No, you can't. If your application has to link with third-party GPLd libraries, such as libsamplerate, liblo, or the KDE libraries, then you have to respect their licences. And that means you can't link with Steinberg's headers and distribute the results (at least as they're licensed at the moment). Chris
Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
On Monday 11 Apr 2005 14:14, Dave Phillips wrote: 1. The vstserver project is functionally dead. It cannot work with newer versions of WINE, and it appears that Kjetil does not plan to keep it updated to accommodate the new versions. Alas, this also means that his nice vsti, ladspavst, and k_vst~ projects are also unusable. :( This does seem to be the case. There doesn't seem to be anything fundamentally wrong with vstserver, but its choice of threading library doesn't work well with recent versions of Wine for some reason. 2. The libfst project is essentially unmaintained. Again, WINE versions wreak havoc with users who want to keep both fst and WINE up-to-date. Paul and/or Torben: Is the libfst project going to see any more activity from your end, or should it be considered an open project and up for grabs ? I think libfst in the form in which you can obtain it currently is also effectively dead. It's very sensitive to Wine version and no longer easy to get working, it's apparently been superseded (has anyone actually seen xfst? I haven't), and it's never been properly licenced. 3. The dssi-vst bridge is still unknown to me because of issues with RH9, and I've not had time to test it on FC3. But is there any general feeling that dssi-vst is a better route to take, at least for the normal user ? Of the three, dssi-vst is I think the easiest to get working with arbitrary versions of Wine, and possibly the best supported (which is not saying much, as I don't exactly get much time to devote to problems on the DSSI list). In my experience problems more often arise from winemaker build system changes or Wine configuration file layout changes than from actual library incompatibilities. I don't know what your problems with RedHat or Fedora were (although RH9/CCRMA was one of my development platforms for dssi-vst, so I'm surprised you had problems with it) but I'll bet you a fiver it's something to do with the build system or config files rather than the library API. We currently use dssi-vst with Wine 200407-something as the basis of VST support in Fervent Studio to Go!, and so I think it works pretty well and I do have a pretty strong incentive to keep developing it, although I don't necessarily always keep up with the very latest versions of Wine. One thing that distinguishes dssi-vst from vstserver and jack-fst is that it manages threading in the Windows parts of the code using the Windows threads API rather than pthreads, which means it ought not to be sensitive to threading-related changes in Wine. Of course, that's only theory. Btw, I like the DSSI API, but it seems slow in catching on with developers. Is that perception correct ? Yes, I think so. I do think you have to bear in mind that the pool of Linux audio developers is also still rather small. It's not like there have ever been many people writing LADSPA plugins either -- the situation there is just distorted by the few authors who have produced dozens. Any system with a good supporting library for simple builds of pretty plugins is going to do better, and for some reason nobody has seen that as an interesting thing to develop for DSSI, or else has had the time to do it. The API may be fairly simple, but it's apparently still a bit tricky to get going with, and there isn't a critical mass of developers or example code. What we really need is the equivalent of VST's SynthEdit. (I don't want to hear arguments that SynthEdit encourages low-quality all-icing plugins -- in my view it's a really effective enabler for people to do interesting DSP assemblies on their own with usable results, and I'd rather support the existing body of SynthEdit synths than a hundred glossy commercial offerings.) That said, it's still the best practical option. It has reasonably widespread support -- it's supported by Rosegarden and in CVS versions of MusE, there are two standalone hosts, it has a handful of dedicated plugins and a pretty decent VST bridge. It has developers who although short of time will do their best to help out, and who do care about the project. (If only I had more time, there are at least a dozen DSSI plugins and wrappers I'd like to be writing. Maybe I should compile a list of ideas and implementation sketches and stick them on the DSSI website in case anyone else would like to have a go. I know most people don't like working from other people's suggestions, though.) Chris
Re: [linux-audio-dev] Re: [linux-audio-user] Concerning libfst, vstserver, and dssi-vst
On Monday 11 Apr 2005 18:03, Kjetil Svalastog Matheussen wrote: I think dssi-vst looks very nice too (although I haven't tried it), and its very similar to the way vstserver works. It should not be much work to make vsti, ladspavst and k_vst~ work with dssi-vst instead of vstserver. Agreed entirely -- structurally they're practically identical. Chris
Re: [linux-audio-user] Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
On Monday 11 Apr 2005 23:19, Paul Davis wrote: longer easy to get working, it's apparently been superseded (has anyone actually seen xfst? I haven't), torben has done a couple of small test releases to people he communicates with via IRC. Ah. No point talking about it here then. and it's never been properly licenced. the license situation is never going to be clear until Steinberg clean up their act. No, the licence situation is clear enough I think. It just isn't very satisfactory. You can't legally link anything that uses the Steinberg headers into a GPL application and distribute the results as a binary, with or without source. dssi-vst is a plugin with very particular licensing -- this legal situation is one reason it is a plugin in the first place, instead of being something built-in to Rosegarden. People from Steinberg have indicated on several occasions that they would happily change the VST SDK licence to BSD or similar. (Well, you know that, and probably more for all I know.) It just never seems to have actually happened. Chris
Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
On Monday 11 Apr 2005 23:19, Paul Davis wrote: the problem is that there is no single answer. if you want to run 1 or 3 VSTi's then i would agree with chris' assessment (for now, anyway). but you cannot use this model to put a VST EQ on 12 tracks and a VST delay unit on 2 others and a VST looper on another. the architecture doesn't scale. The VST-per-server implementation might not, but there's no very compelling reason not to have multiple VSTs in a single server serving multiple clients. That would be less reliable than a dssi-vst type service can be, but no less reliable than fst, and it should scale nearly as well. It's been on my todo list for ages... Chris
Re: [linux-audio-dev] Creating the conditions for VST-like plugins on Linux.
On Friday 08 Apr 2005 18:57, Juan Linietsky wrote: So, I'm sure that many of you have asked yourselves, why cant we have a VST-like plugin architecture for Linux? The following are excuses: No, they're reasons. They may not be the principal reason, but they're not excuses. Nobody claims that GUI/plugin separation or whatever is the principal reason for designing or using something like DSSI. The principal reason is that we don't have anything currently that addresses the same requirements -- to provide something that works for a good number of users. DSSI is built from necessity, but it's certainly nice to have something designed for controllability in as many different ways as possible. And I say, ALL THIS IS LIES. I admire your conviction. Every single of such reasons are of no concern to musicans. You're a developer. Your email is written from a developer's point of view. The purpose of your email is to propose a significant development project. Please don't try to claim that you're writing on behalf of musicians who have no concern for the interests of developers. If I just want to make music, I would not care about any of such reasons. I'd just fire up an application and make music. And you wouldn't care about Juan Linietsky's pet development project. I only wish I had a bit of free development time myself at the moment. Your Chionic sampler looks like something that can quite easily be made into a DSSI plugin, and it would be an excellent source of reusable material for other plugins that want to do similar things. It's a shame you want to channel your energy away from such a useful project, at least without even giving it a serious try. That's laziness too, you know. Chris
Re: [linux-audio-dev] Creating the conditions for VST-like plugins on Linux.
On Friday 08 Apr 2005 18:57, Juan Linietsky wrote: Also there is the need for instrument plugins, single or multi timbral (so you dont have to load all the instances at once). DSSI provides this (except the multitimbral) Sorry, can you explain that last (bracketed) bit? Chris
Re: [linux-audio-dev] Quick question regarding raw midi access via alsa sequencer
On Friday 18 Mar 2005 15:40, Ivica Ico Bukvic wrote: 2) The other option is obviously to use alsa-sequencer API but in that case is there a way to simply convert the stream of received MIDI data into raw midi format so that I can use my built-in raw MIDI parsing engine for parsing the messages? If I understand the requirement right, then the snd_midi_event_* API can do it: see alsa/seq_midi_event.h. I've used this a couple of times in the DSSI examples source code, and I'm sure there are plenty of examples elsewhere. Chris
Re: [linux-audio-dev] ANNOUNCE: Rosegarden-4 1.0 released!
On Tuesday 15 Feb 2005 14:25, Dave Phillips wrote: Now if I can just get some sound from RG I'll be all set... *sigh* Save it for after the release party already! OK, OK... Have you tried playing it to aspymidi or similar? What does that have to say? Chris
Re: [linux-audio-dev] ANNOUNCE: Rosegarden-4 1.0 released!
On Tuesday 15 Feb 2005 16:28, Dave Phillips wrote: Relax, enjoy the party. I followed Andre's lead, removed the old file, all is well in RG4 1.0... so far... ;) Phew! I don't suppose either of you kept a copy of the old file you could send me, so I can see if I can work out what caused the problem? Chris
[linux-audio-dev] ANNOUNCE: Rosegarden-4 1.0 released!
ROSEGARDEN-4 1.0 RELEASED! == LONDON, CANNES, ETC., FEBRUARY 14th 2005 -- The Rosegarden team are delighted to announce the 1.0 release of Rosegarden 4, an audio and MIDI sequencer and musical notation editor for Linux. Rosegarden is one of the most comprehensive Linux music software projects, and is the only Linux application to offer full composition and recording capabilities to musicians who prefer to use classical notation. http://www.rosegardenmusic.com/ http://www.rosegardenmusic.com/getting/ http://www.rosegardenmusic.com/support/ Some of Rosegarden's features are: o MIDI and audio playback and recording with ALSA and JACK o Piano-roll, score, event list and track overview editors o DSSI synth and audio effects plugin support, including Windows VST effects and instrument support via dssi-vst o LADSPA audio effects plugin support o JACK transport support for synchronisation with other software o Ability to build and run without JACK, for MIDI-only use o Score interpretation of performance MIDI data o Shareable device (.rgd) files to ease MIDI portability o Triggered segments for pattern sequencing performable ornaments o Audio and MIDI mixers o MIDI and Hydrogen file import o MIDI, Csound, Lilypond and MusicXML file export o Clear, consistent and polished user interface o User interface translations for Russian, Spanish, German, French, Welsh, Italian, Swedish, Estonian, Japanese, and Simplified Chinese, as well as UK and US English o Help documentation available substantially or entirely translated into German, Swedish and Japanese as well as English. Rosegarden is Free Software under the GNU General Public License. Chris
Re: [linux-audio-dev] Developing a music editor/sequencer
On Wednesday 02 Feb 2005 17:21, NadaSpam wrote: This is my initial stab at a development plan. I'm tentatively calling this project Scortch. Scorch is a registered trademark of Sibelius. It's probably wise to avoid choosing a name that sounds the same. http://www.sibelius.com/products/scorch/ Chris
Re: [linux-audio-dev] Developing a music editor/sequencer
On Wednesday 02 Feb 2005 19:02, Paul Davis wrote: I continue to think that this crazy. So do I. The design process at work here reminds me a lot of the way I approached Rosegarden: look at how other applications work and what they do, and then add in a few interesting generalisations to make it more potentially flexible in ways that happen to meet my own preconceptions about how people might use the system, thus resulting in something that looks innovative and interesting to me, and just looks like another sequencer or score editor to everyone else. For example, Rosegarden contains structure intended to support things like arbitrary layout engines for editing; multiple different layouts on the same music data; event-based systems that are not MIDI, and so on. Yet because it has taken so much development work just to do the basic MIDI and audio support that people expect from a sequencer, and because we are so few developers, most of this is still unused. It would have been far better, for my own personal aims, to have worked on something that was not so obviously a sequencer application and that instead focused on the one or two experimental features I was really interested in and ignored everything else. Don't get me wrong: I think Rosegarden is a successful piece of work and I'm very proud of it. But if I was starting out now, I wouldn't be working on anything like it. You should see some of our planning emails from five years ago, excitedly talking about how we just had to do one or two generic bits and bobs and the rest would simply fall into place. It's a very hard delusion to avoid, but it's always a delusion anyway. Chris
Re: [linux-audio-dev] Developing a music editor/sequencer
On Wednesday 02 Feb 2005 19:49, Chris Cannam wrote: You should see some of our planning emails from five years ago, excitedly talking about how we just had to do one or two generic bits and bobs and the rest would simply fall into place. ... and five years ago we were already on our third iteration of the Rosegarden project, so we really should have known better already! Chris
Re: [linux-audio-dev] Plans/Roadmaps for 2005?
On Saturday 08 Jan 2005 13:26, Comix wrote: |- Support of plugin instrument (dssi?vsti?others?) The dssi-vst bridge plugin is pretty decent now, so I'd suggest that doing DSSI support is quite a good way to get VSTi support -- at least for 32-bit Windows VST plugins. That way everyone wins: you get more plugins supported more easily, DSSI gets more exposure, and dssi-vst gets more testing and improvements and quirk fixes can be concentrated in a single place. Besides VST instrument plugins, dssi-vst is also an easy way to get VST effects support. You have LADSPA, so if you're adding DSSI GUI support for synth plugins in any case, then you'll get DSSI effects support (and VST effects support with GUIs, and DSSI GUIs for LADSPA plugins) pretty much free because DSSI is compatible with LADSPA for effects. I'll be happy to provide help and explanation for anyone thinking of working on a DSSI host -- although there's a lot of documentation and example code already. A related thing I'd like to see is a DSSI synth plugin that plays Hydrogen drumkits. I nearly wrote one a few weeks ago, but, well, time didn't quite permit... Chris
Re: [linux-audio-dev] provding plugins with various in/out counts vs. using splitters-mergers
On Tuesday 04 Jan 2005 21:00, Paul Davis wrote: ardour-dev has nothing. we do almost all discussion on IRC these days. Ah. Does that get logged anywhere? the only argument i can see in favor of at least some 2in/2out plugins having a 1in/2out cousin is that their DSP algorithms are actually different in each case. Can't argue with that. Chris
Re: [linux-audio-dev] provding plugins with various in/out counts vs. using splitters-mergers
On Tuesday 04 Jan 2005 20:20, Dave Robillard wrote: Personally, I think it's a disgusting waste of time and effort to make every stereo plugin have to have a mono-stereo sibling. It just /screams/ bad solution. I agree, it sounds ridiculous -- on first hearing at least. I'm going to have to go and read some of this ardour-dev discussion (it's not a list I subscribe to) and see if it makes any more sense to me then. I realise it's not easy (or even always possible) to do the Right Thing in the host -- my own host has some way to go too -- but I don't understand why it should be better to create dozens of spurious plugins than to give the user the information they need and let them decide how a plugin should be handled. Chris
Re: [linux-audio-dev] rosegarden, alsa_seq and usx2y rawusb
On Sunday 12 Dec 2004 22:44, Uwe Koloska wrote: But when starting jack with driver 'usx2y' the midi seems not to arrive at ZynAddSubFX (or Hydrogen or fluidsynth or ...) Try changing Rosegarden's Sequencer Timer setting (Settings - Configure Rosegarden - Sequencer - Synchronisation) to system timer, or something else other than (auto). Chris
Re: [linux-audio-user] Re: [linux-audio-dev] dssi question
On Sunday 05 Dec 2004 22:38, Hans Fugal wrote: The DSSI JACK host will always try to start a user interface for each plugin it loads. (It could easily have a command line switch to tell it not to, but there isn't one at the moment.) Attached is a patch. Committed to DSSI CVS, thanks. Chris
Re: [linux-audio-dev] dssi question
On Sunday 05 Dec 2004 11:37, Julien Claassen wrote: I've just one important - for me at least - question. Can the jack example client be used without gui? Can it be used with midi only? Yes and no. The DSSI JACK host will always try to start a user interface for each plugin it loads. (It could easily have a command line switch to tell it not to, but there isn't one at the moment.) However, if no user interface executable is found, it will continue happily without. So you could make it never start a UI by simply not installing any UIs. It will still continue to deliver MIDI and produce audio. Also, DSSI user interfaces have no obligation to be graphical. The DSSI UI mechanism is a simple Open Sound Control protocol, and you can control it from any OSC client. You can provide many UIs for a single plugin, and the host will choose one or support many at once -- again, the JACK host is probably not optimal here as it offers no way for you to specify which UI to prefer. (I haven't tested it with multiple simultaneous UIs.) The DSSI package also includes a command-line tool (dssi_osc_send) that you can use to control the ports, parameters, and configuration of any loaded DSSI plugin without explicitly using a UI at all. So most of the bits you need are there, but their organisation can probably be improved upon. Any suggestions for particular use cases will be warmly received. Chris
Re: [linux-audio-dev] Rosegarden: All Notes OFF
On Wednesday 24 Nov 2004 22:06, Jens M Andreasen wrote: According to my oldish midi-spec, controller (decimal) 120 is undefined, so I was somewhat confused at first when I got it from Rosegarden. A bit of digging shows that it belongs to the (newish?) GS-spec, and means All-Sound-Off (as in 'killall -9') Ah, that controller. This is what happens when you rely on public interpretations of a proprietary spec. Quite a few sources claim this controller _is_ in MIDI 1.0, and since most contemporary synths interpret it as expected (silencing all notes even if sustain is active), the matter wasn't ever really questioned. Anyway, it turns out that besides some synths not understanding this controller at all, there are some that treat it the same as all notes off (i.e. not silencing sustained notes) and others that appear to interpret it as meaning they should shut up forever and never play another note. So, recent Rosegarden CVS versions instead send all notes off and switch off any sustain explicitly. Chris
[linux-audio-dev] Re: [linux-audio-user] RE: [OT] Wired GPL Audio/MIDI sequencer
On Monday 15 Nov 2004 13:56, Kjetil Svalastog Matheussen wrote: This is a great idea, where it should be easy to make a general library for other hosts (not necesarrily running Qt) making use of those UI's with the help of some ipc-tricks. And to complete the circle: an obvious choice of ipc-trick would be just to use the same OSC-based communications as used for DSSI plugin GUIs (trivial to implement using Steve Harris's liblo library). Thus enabling DSSI hosts to use them for free, and anything else to use them for fairly cheap. Nice idea for a little project for anyone with a few hours to spare. Chris
[linux-audio-dev] [ANN] DSSI 0.9 released
DSSI v0.9 released == I'm happy to announce version 0.9 of the DSSI plugin API. http://dssi.sourceforge.net/ DSSI is an audio plugin API designed for software instruments with custom user interfaces. DSSI is based on the LADSPA effects plugin API, the ALSA sequencer event types, and OSC (Open Sound Control) communications. It's intended to be easily understood, GUI-toolkit-agnostic, and slightly biased towards familiarity with MIDI. The DSSI distribution package contains a JACK/ALSA-sequencer reference host and some plugins as well as the specification and header. DSSI 0.9 was constructed by Steve Harris, Chris Cannam, and Sean Bolton. New in 0.9 -- The main improvements in 0.9 are to the reference host implementation and sample plugins. The 0.9 API itself is binary compatible with the previous 0.4 release. A new convention for plugin-global (rather than instance-local) configuration data and a convention for setting a plugin's project working directory have been introduced, and 0.9 clarifies certain implementation points in the documentation. Available hosts and plugins --- Two hosts are currently known to include complete or nearly-complete DSSI support: the reference jack-dssi-host included in the DSSI 0.9 distribution, and versions 0.9.9 and later of the Rosegarden-4 sequencer. Currently available plugins include: * a FluidSynth soundfont plugin included in the DSSI distribution * Xsynth-DSSI, an analog-style (VCAs-VCF-VCO) plugin * dssi-vst, a wrapper plugin enabling the use of many Windows VST instruments and effects * hexter, a Yamaha DX7 modeling plugin * three smaller example plugins (two synths and a sampler) that are also part of the DSSI distribution.
[linux-audio-dev] [ANN] dssi-vst 0.3
dssi-vst 0.3 released! == The 0.3 release of dssi-vst is now available. dssi-vst is a DSSI plugin wrapper for VST effects and instruments with GUI support, allowing them to be loaded into any DSSI host. It requires a fairly recent version of Wine (this calendar year at least). dssi-vst is available from the download page at http://dssi.sourceforge.net/ The main improvement since the initial 0.1 release is that dssi-vst now works correctly with plugins with complex GUIs that use back-channel information to communicate things like patch data to the audio plugin. In practical terms, this means that VSTs with test keyboard widgets, patch load and save, and other natty features in their GUIs should work properly as DSSI plugins without losing automatability for the true automatable parameters.
Re: [linux-audio-dev] Sequencer cursor
On Monday 25 Oct 2004 16:26, Dave Phillips wrote: The use of the computer keyboard in Sequencer Plus is the main reason I keep using it. MusE, RG, and the crop of Windoze MIDI sequencers are all very nice, but they all presume that my working method will be mouse MIDI-keyboard centric. I won't deny that Rosegarden is mouse-centric, but it does allow you to type notes from the PC keyboard in different octaves and any available durations, and select, transpose, cut, copy, paste and delete them etc, without using the mouse or a MIDI keyboard. You can't currently do much at the segment editing level from the keyboard though. Chris
Re: [linux-audio-dev] Re: LAC 2004 recordings now online
On Wednesday 13 Oct 2004 14:09, Juhana Sadeharju wrote: Who are the people in this photo? [...] Please send me names privately. I will make a new image with names attached to it. I think this has already happened, for a slightly different photo but with the same people in it. Jan Depner had an annotated version online, but it seems it's no longer there. See this thread for details: http://eca.cx/lad/2004/05/0218.html and this email for what I think proved to be the most complete list: http://eca.cx/lad/2004/05/0235.html Chris
Re: [linux-audio-dev] Drum synth
On Saturday 18 Sep 2004 23:17, Dmitry Baikov wrote: Drumatic-VST also segfaults. I use Drumatic as a DSSI plugin through the DSSI-VST bridge (dssi-vst.so, see http://www.sf.net/projects/dssi, http://dssi.sf.net/). It works very well for me. I'd love to see a native DSSI drum synth, as I'm sure I've said many times before. With the minimal JACK/ALSA-sequencer host included in the DSSI distribution you can run such a plugin as a standalone synth and drive it from seq24 or any other host that doesn't support DSSI. We'll probably do another release of DSSI quite soon, but it won't have many changes from the last one as the API is stabilising nicely. I'd really encourage anyone thinking of writing a synth, especially a small (from the user point of view) or single-purpose one like this, to consider using DSSI. Chris
[linux-audio-dev] [ANN] dssi-vst 0.1
dssi-vst is a DSSI wrapper plugin for VST plugins. It enables any compliant DSSI host to use VST instruments and effects. It requires Wine, liblo-0.9, dssi.h, and the Steinberg VST SDK headers to build. http://sf.net/projects/dssi/ http://www.winehq.org/ http://plugin.org.uk/liblo/ http://www.steinberg.net/steinberg/ygrabit/index.html dssi-vst is self-contained code, it doesn't use vstserver or libfst. There's no very compelling reason for that, and there's nothing inventive about it, but it works quite well for me with all two of the existing DSSI hosts. dssi-vst is licenced under the GPL with an additional exemption to cover the non-redistributability of the Steinberg SDK headers. This means it is technically not Free Software in the Debian/FSF sense. Again, see the README for more details. Chris
[linux-audio-dev] DSSI (Disposable Soft Synth Interface) 0.4
I'd like to announce a new version (numbered 0.4) of the DSSI synth plugin API proposal. http://dssi.sourceforge.net/ 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. DSSI 0.4 was constructed by Steve Harris, Chris Cannam, and Sean Bolton. DSSI is intended to be simple, especially for plugins; GUI-toolkit-agnostic; and slightly biased towards familiarity with MIDI. It's proposed as an interim measure until bigger and better things come along: hence disposable. The 0.4 release addresses the problem of efficiently managing shared resources among instances of a plugin by providing explicit support for plugins that may be run in a group. It also clarifies issues such as thread-safety and fixes a few other problems with the 0.1 API identified on LAD and elsewhere. We think the 1.0 release could look pretty much the same as this 0.4 version, barring any more stupid mistakes. The release contains the RFC, the dssi.h header file, example host and plugin code, and now the all-important FluidSynth wrapper plugin. Comments to LAD please. Chris
Re: [linux-audio-dev] Tutorial on Professional Audio GNU/Linux Tools
On Wednesday 14 Jul 2004 1:40 pm, Maarten de Boer wrote: - jack configured at 44100 Hz [...] * Alsa 1.0.5a This combination won't work for synchronised MIDI and audio with Rosegarden. The ALSA PCM timer (which Rosegarden 0.9.8 uses by default when JACK is running) miscalculates the interrupt frequency at 44100: http://sourceforge.net/mailarchive/message.php?msg_id=8855303 It's fixed in ALSA CVS, but not in a release yet. Chris
