[linux-audio-dev] distros: don't package hexter 0.6.0
Hi all, If you're thinking of packaging hexter 0.6.0 for your favorite distribution, please wait for version 0.6.1. I've been talking with Anthony Green about his efforts to package hexter 0.6.0 for Fedora, and it seems I made a mistake. hexter 0.6.0 can sound radically different from hexter 0.5.9, depending on the patch used, and I didn't want anyone's existing projects to break if they upgraded. So I changed the way hexter 0.6.0 installs: it installs as hexter6.so, while hexter 0.5.9 installs as hexter.so, so the two versions can coexist. This works well enough for people who install from source, but Anthony pointed out that this makes things difficult for people packaging hexter for distributions. For most distros, when one upgrades, the old files are removed, meaning hexter.so would disappear and existing projects would break. Distros with something akin to Gentoo's SLOT mechanism can have multiple versions installed simultaneously, but the majority of hexter users will have no need for anything but the latest version. What I'm going to do with version 0.6.1 instead is make it install as hexter.so, just like 0.5.x versions, and add a configuration option which will optionally make it sound like 0.5.9. Problem solved: existing projects can easily be made to sound like they originally did, and everyone can have the latest and greatest hexter installed. Expect 0.6.1 sometime this coming week. Thanks, Sean Bolton
Re: [linux-audio-dev] distros: don't package hexter 0.6.0
On Mar 8, 2007, at 2:52 PM, Chris Cannam wrote: a configuration option Build configuration, or DSSI configure() ? DSSI configure -- I should have said 'a run-time configuration option', would have been less confusing. Only one hexter.so to install, with a little checkbox in the GUI to make it backward compatible. -Sean
[linux-audio-dev] [ANN] hexter 0.6.0
Announcing a new release of the hexter DSSI plugin. http://sourceforge.net/project/showfiles.php? group_id=104230package_id=134428 hexter is a software synthesizer that models the sound generation of a Yamaha DX7 synthesizer. It can easily load most DX7 patch bank files, accept patch editing commands via MIDI sys-ex messages, and recreate the sound of the DX7 with greater accuracy than any other open-source emulation (that the author is aware of...) hexter operates as a plugin for the Disposable Soft Synth Interface (DSSI). New features in version 0.6.0 include: * Implemented the LFO, amplitude modulation and pitch modulation (many thanks to Jamie Bullock)! * Added TX7-style performance parameters, allowing configuration from the GUI of pitch bend range, portamento time, and sensitivity and assignment of the modulation wheel, foot controller, pressure (both channel and key), and breath controller. * Added DX7 patchbank loading code from Martin Tarenskeen, allowing hexter to load a number of additional patch file formats. * Partially implemented portamento. For now, the curves and times are wrong, but the plumbing is there. More information about hexter and DSSI can be found at: http://dssi.sourceforge.net/hexter.html hexter is written by Sean Bolton, and copyright (c)2007 under the GNU General Public License, version 2 or later.
[linux-audio-dev] [ANN] ghostess 20061127 release
Announcing the latest release of ghostess, a lightweight Gtk+ host for DSSI plugins: http://home.jps.net/~musound/ghostess-20061127.tar.gz New in this release: - bug fixes, build enhancements and code cleanups. - code to export patch lists to Freewheeling. - support for the latest JACK MIDI transport. - blinky lights indicating MIDI activity. ghostess is written by Sean Bolton, and copyright (c)2006 under the GNU General Public License, version 2 or later. DSSI is an audio plugin API for software instruments and effects, based on LADSPA, the ALSA sequencer event types, and OSC (Open Sound Control) communications. Learn more about it here: http://dssi.sourceforge.net/ Enjoy! -Sean
Re: [linux-audio-dev] Todays changes to LADSPA2 strawman
On Apr 29, 2006, at 9:42 AM, Dave Robillard wrote: On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote: 4) the run_multiple*() callbacks (how many plugins use these?) Silly useless function. Toss it on the trash heap with run_adding. Dave, you complain about people talking down about modular synths, then yourself discount things that are only useful in non-modular designs? How about a little reciprocity here? run_multiple_synths() _is_ useless to any host (like Om), that wants to process an arbitrary connection graph one node at a time. run_multiple_synths() is very useful when a host can run multiple instances of a plugin at once. It provides easy, lock-free sharing of resources across the instances. It allows FluidSynth-DSSI and hexter to both provide a shared pool of voices used across several instances, with _sample-accurate_ voice stealing. It allows FluidSynth-DSSI to easily bolt onto libfluidsynth, and share soundfont data between multiple instances, without the need for a custom soundfont loader. In contrast, I purposely wrote WhySynth without using run_multiple_synths(), just to see how difficult the resource sharing would be. Nasty mess of mutexes and try_locks() All of this is not to say that run_multiple_synths() doesn't have some real PITA issues. But that's a discussion better had over on dssi-devel. -Sean
Re: [linux-audio-dev] LADSPA2: logarithmic hint
On Apr 28, 2006, at 1:30 AM, Steve Harris wrote: On Thu, Apr 27, 2006 at 08:39:06AM -0700, Sean Bolton wrote: Okay, Steve, I trust you have something ready to go that you feel will replace it, but I'm still worried. The discussion you and Paul had on this list sounded to me like you were both conflating the need for scaling a linear range (widget or MIDI CC) to an exponential one (e.g. frequency port), with the need to provide unit labels for port values (e.g. dBFS). The two are independent, and I agree with Dave that the log scaling hint is essential. It does work when bounds are sensibly specified (i.e. don't include zero), and needs to be extended -- not dropped -- to handle the other common cases people try to (ab)use it for. Sure, the problem is that the log hint doesn't actually do what you want. The only time I use it is for frequency ports. Extending it so that it can cover that case would be really hard, and it only covers the one case, so you may as well just say this is a frequency. snip So, what you really need is the information about what the port is actualy representing, that way the hosts can make an intelligent choice about how to map it to a UI feature. eg. a pitch mapping for frequency inputs, and an IEC scale for dBs. Yikes, now I'm sure this is headed the wrong direction! Say you specify that a port is representing frequency -- is it a pitch multiplier, where the 'knob' should be scaled by pitch (i.e. log(frequency)), or does it refer to an FFT bin, so that it should be scaled linearly? How about a delay time whose unit is 'seconds'? Log or linear scaling? Or a distortion drive control whose unit is technically 'radians'? How's a host supposed to figure out how to scale that? What should it do with a 'magnification' port that is unitless? It's not possible for a host to know how to scale a port from just the unit labeling. Unit labeling and input value scaling are independent, in fact are completely orthogonal except in certain conventional cases like IEC for some (not all!) dB ranges. I'm okay waiting until the base LADSPA2 spec is done to figure this part out, to keep the confusion down, so long as we all realize that until we do, LADSPA2 hosts will be even more clumsy in this regard than LADSPA 1 hosts currently are. And Steve -- setting my knit-picking here aside ;-) -- thank you very much for all your work on this! -Sean
[linux-audio-dev] [ANN] WhySynth DSSI plugin 20060122 release
Announcing the 20060122 release of WhySynth, a DSSI softsynth plugin. New since the last major release: * A new oscillator mode, based on Nasca O. Paul's gorgeous PADsynth algorithm. * A new filter mode, essentially the low-pass filter from amSynth. * A new dual delay effect. * Improved and extended wavetables. * More patches. * Lots of cleanups and bug fixes, including fixes for more stable operation especially under Rosegarden, and for compilation on Mac OS X 10.4 'Tiger'. Find WhySynth here: http://home.jps.net/~musound/whysynth.html More information on the DSSI plugin standard, available hosts and plugins can be found here: http://dssi.sourceforge.net/ WhySynth is written and copyright (c) 2006 by Sean Bolton, under the GNU General Public License, version 2.
[linux-audio-dev] hexter DSSI plugin 0.5.9
A minor update of hexter, the Yamaha DX7 modeling DSSI plugin, is now available at: http://sourceforge.net/project/showfiles.php? group_id=104230package_id=134428 Changes include: * The coarse frequency of each operator now can be controlled in real time via MIDI control changes. * Fixes for RPM, gcc 2.9x and 4.x, and Mac OS X 10.4 'Tiger'. More information about hexter and DSSI can be found at: http://dssi.sourceforge.net/hexter.html hexter is written by Sean Bolton, and copyright (c)2006 under the GNU General Public License, version 2 or later.
Re: [linux-audio-dev] defining a platform
Hi Derek, On Dec 24, 2005, at 3:08 AM, derek holzer wrote: I hope this is a simple question. I'm trying to compile Rezound on OSX, and I'm getting this: ../../../config/platform/platform.h:10:3: warning: #warning no platform determined! snip #if defined(__Darwin) #define rez_OS_DARWIN #endif Instead, try: #if (defined(__MACH__) defined(__APPLE__)) HTH, -Sean
[linux-audio-dev] [ANN] DSSI 0.9.1 release
Announcing the DSSI Soft Synth Interface version 0.9.1 release: http://dssi.sourceforge.net/ DSSI is an audio plugin API for software instruments and effects, based on LADSPA, the ALSA sequencer event types, and OSC (Open Sound Control) communications. This release does _not_ contain any changes to the DSSI API itself, which has been stable now since the 0.4 release fifteen months ago (with minor additions at 0.9). Instead, it contains numerous clarifications to the specification and documentation, and the included reference host and example programs have become significantly more robust. Specific changes in 0.9.1 include: - The distribution now has a full autoconf/automake/libtool build system. - FluidSynth-DSSI has been moved into its own package, and no longer depends upon the FluidSynth source. - The reference host, jack-dssi-host, now supports plugins with audio inputs, as well as LADSPA-only plugins (with or without custom DSSI GUIs.) Available hosts and plugins --- More exciting than the changes in this release, is the recent growth in DSSI implementations. Items marked with '*' are new since the DSSI 0.9 release. Available hosts are: - jack-dssi-host, included in the DSSI distribution - the Rosegarden 4 sequencer * Om, a modular synthesizer * ghostess, a lightweight GTK+ host * dssi~, a Pure Data external Efforts are underway to add DSSI hosting to: - the MusE sequencer * Csound5 * GNU Classpath Available plugins include: - the simple synths and sampler in the DSSI distribution - FluidSynth-DSSI, a soundfont-playing plugin - Xsynth-DSSI, an analog-style synth - dssi-vst, a wrapper plugin enabling the use of many Windows VST plugins - hexter, a Yamaha DX7 modeling plugin * ll-scope, an oscilliscope plugin * Sineshaper, a waveshaping soft synth * dssi_convolve, a DSSI wrapper around libconvolve * xy-controller-dssi, a GUI controller plugin which translates mouse input into X-Y control outputs * WhySynth, which offers a number of synthesis methods The Future -- In the year and a half since its initial introduction, DSSI has met a number of challenges to its adoption: the continued (perpetual?) forthcomingness of GMPI, apprehension about adopting a standard with 'Disposable' in its name, some wait and see if takes off attitude, and numerous gripes that it won't do this or can't do that. Even so, the creative potential available through DSSI today is great. In part due to this success, there has been a noticable commitment voiced in recent discussions on the DSSI email list to keeping any future enhancements backward-compatible with the existing DSSI API. In the author's opinion, this indicates DSSI will continue to be a stable API, at least until such time as a '2.0' version is considered. With regard to possible future enhancements, interest has been highest in two areas: providing plugins with transport position and tempo information, and allowing plugins to send MIDI data. If you're interested in helping shape these or other developments, please join us on the DSSI discussion list.
Re: [linux-audio-dev] [ANN] WhySynth DSSI softsynth
On Oct 9, 2005, at 11:18 AM, Jens M Andreasen wrote:
Let Bolton speak for himself, please. Gentlemen please ...
Bolton speaks for himself, thusly:
On Oct 8, 2005, at 10:30 PM, Jens M Andreasen wrote:
Whoaa!
Some really impressive specs. Are you trying to corner the market as in
the only soffsynth you'll ever, ever need!! :)
Right-o, as in Guinness is the only beer you'll ever, ever need,
and Gentoo is the only distro you'll ever, ever need!!
Do you have some rough statistics on number of voices/gigahertz?
That depends on the patch. With a simple two-oscillator, single filter
patch playing 16 voices, my 933MHz Pentium 3 barely breaks a sweat
(17% CPU according to top, 22% according to qjackctl). One the other
hand, with the most expensive patch I can think of, it maxes out at
only two voices.
On Oct 9, 2005, at 3:33 AM, Jens M Andreasen wrote:
WhySynth, as in (I sometimes ask), _why_ am I working on another
softsynth instead of on paying gigs? (Following my bliss?
Addiction? One last shot at misspent youth?)
Heh :) Once you have done one, you are addicted.
This is not nescessarily a bad thing. Laying out a synthesizer
requires
as much consideration as laying out say; the main theme for film-score.
A few cycles of scrapping and reinventing is expected, perhaps even
required.
Yeah, addicted is right. I code in a very experimental, improvisational
way. If I could manage only a _few_ cycles of scrapping and
reinventing,
I would be much more efficient!
On Oct 9, 2005, at 8:45 AM, derek holzer wrote:
Very nice, hours of fun in there to be sure. But how can you handle
MIDI bindings? For example, to control one of the filter resonance
knobs rather than just the MIDI note/pitchwheel in?
That's one of the things I haven't done yet, and one of the awkward
parts of DSSI. Several people (two?) have pointed out that DSSI
provides for binding MIDI CCs/NRPNs to ports ('knobs'), but the plugin
must declare these bindings to the host before the GUI gets a chance
to run. So you either have to make them hard-coded, or require
the user to exit-and-restart in order to implement custom bindings.
If you wanna hard-code your own bindings, I'll tell you how
(Just look in src/dssp_synth.c for the Y_PORT_GLIDE_TIME binding
to the MIDI portamento time CC, follow the example, and recompile :-/)
Thanks, everyone, for your comments and questions,
-Sean
[linux-audio-dev] [ANN] WhySynth DSSI softsynth
Introducing WhySynth, a DSSI softsynth plugin. WhySynth, as in 'Y'-synth, the super-sized, frankensteinized, evolved and mutated, still rather dorky younger sibling of Xsynth-DSSI. WhySynth, as in (I sometimes ask), _why_ am I working on another softsynth instead of on paying gigs? (Following my bliss? Addiction? One last shot at misspent youth?) WhySynth, as in a mostly-new design featuring: - 4 oscillators per voice, in your choice of 6 modes (minBLEP, wavecycle, asynchronous granular, FM, waveshaper, and noise), - 2 filters, also in multiple flavors, - flexible routing and mixdown to stereo output, - 3 (or is it 6?) LFOs (instrument-wide, per-voice, and multiphase), - 5 multi-mode envelope generators, - abundant modulation options, - and effects (well, Tim Goetze's Versatile plate reverb is all at the moment, unless you count the DC-blocker anti-effect). WhySynth is a work in progress. Actually, since the kid was born, progress has slowed to a near-utter standstill, but if I can't release often, I might as well release early. Get your tarball, boring screenshot, and html-ized README today at: http://home.jps.net/~musound/whysynth.html then get your butts back to making cool music -- however you define that. Cheers, -Sean
Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst
Torben, On Apr 12, 2005, at 11:05 AM, [EMAIL PROTECTED] wrote: dssi needs jacktransport awareness. To me, DSSI's neutrality with regard to audio input/output and MIDI input is one of its advantages: the same plugin will work whether running under JACK and ALSA, or OSS, or CoreAudio and CoreMIDI, or whatever -- only the host need be aware of the particular implementation. So I'm curious: what sort of uses do you have in mind for a DSSI-like plugin system, that it would need JACK transport awareness? -Sean
[linux-audio-dev] [ANN] blepvco 0.1.0 - LADSPA minBLEP hard-syncable VCOs
Announcing blepvco 0.1.0: http://home.jps.net/~musound/blepvco-0.1.0.tar.gz blepvco is a LADSPA plugin library containing three anti-aliased, minBLEP-based, hard-sync-capable oscillator plugins. The oscillators are intended to be used with modular synthesis systems, such as Alsa Modular Synth (a couple example AMS patches are included). The three oscillators are: Sync-Saw-VCO : Anti-aliased sawtooth oscillator with hard-sync capability Sync-Rect-VCO : Anti-aliased variable-width rectangle oscillator, with sync Sync-Tri-VCO : Anti-aliased variable-slope triangle oscillator, with sync Users of Fons Adriaensen's VCO-plugins will find these plugins immediately familiar, since they borrow much of their interface code from Fons' work -- indeed, if/when you do not need the hard-sync or variable-slope triangle wave features of blepvco, his plugins may be a better choice, because their CPU use is somewhat lower. Currently, his VCO-plugins can be found at: http://users.skynet.be/solaris/linuxaudio/ blepvco is written by Sean Bolton, and copyright (c)2005 under the GNU General Public License, version 2 or later. Much thanks to Fons, Daniel Werner, Tim Stilson and Julius Smith, and Eli Brandt.
Re: [linux-audio-dev] Tuning
On Jan 28, 2005, at 6:57 AM, [EMAIL PROTECTED] wrote: One thing I haven't been able to replace so far is the Oberheim OB-Tune plug-in. .. There were a number of ways to use it. You could define a set of notes that were allowed, and audio would be made to be in tune with the closest note (useful for phrases) or you could specify a single note. This was all parameterised, so you could write changes to these throughout a track. On Jan 28, 2005, at 7:52 AM, Alfons Adriaensen wrote: There is no general 'data' interface to LADSPA ... ...but DSSI provides the needed data interface: define groups of parameter settings (temperament, note sets, etc.) using its configure() method, then select these setting groups throughout the track using program changes. -Sean
[linux-audio-dev] [ANNOUNCE] hexter DSSI plugin 0.5.8
A minor update of hexter, the Yamaha DX7 modeling DSSI plugin, is now available at: http://sourceforge.net/project/showfiles.php? group_id=104230package_id=134428 Changes include: * Now uses GTK+ 2.x by default. GTK+ 1.2 and a minimal text- based UI are also available. * Added an output gain control, and corrected the MIDI controller 7 volume handling. * Several small bug fixes. More information about hexter and DSSI can be found at: http://dssi.sourceforge.net/hexter.html hexter is written by Sean Bolton, and copyright (c)2005 under the GNU General Public License, version 2 or later.
Re: [linux-audio-dev] dssi plugins / UIs - compiling without ui
On Dec 17, 2004, at 2:59 PM, Julien Claassen wrote: I've got a question: Could you give an option to the configure scripts (for hexter and the like) to NOT compile the GUIs? I've got a problem with the guis, for I don't have a lot of the graphic devel stuff installed. This would be very kind! Text-based UIs are possible for DSSI plugins, but nobody had every written one (as far as I know). So your request motivated me to actually attempt one. I've got a _very_ rough and minimal start to a readline/ncurses based UI for hexter. You can try it out at: http://home.jps.net/~musound/hexter-0.5.7-julien.tar.gz Start it up with jack-dssi-host (as is suggested in the README), and type 'help' at the prompt for options. Control-T functions as the 'Play Test Note' button. As to text-based UIs, I've looked into the simple_sampler UI, but don't understand it yet (very much)... :-) I've to continue looking into it, I'm not a very good programmer. But I'll do it! Part of the reason (aside from lack of time) I didn't implement more in the text UI, is I'm hoping it might provide a good jumping-off point for your programming efforts! The structure of the GTK+ and text UIs is parallel, so you'll have the GTK+ code to guide you. Let me know (off-list) if you have trouble getting this working. -Sean
[linux-audio-dev] [ANN] hexter DX7 modeling DSSI plugin
Announcing the first public release of the hexter DSSI plugin. http://dssi.sourceforge.net/hexter.html hexter is a software synthesizer that models the sound generation of a Yamaha DX7 synthesizer. Now you can have the sparkling, richly evolving sounds of this classic FM synth on your Linux workstation! There are a few things still missing from hexter's emulation of the DX7 (and it doesn't attempt more general FM synthesis like Native Instrument's FM7), however, even at its current stage of development, it is quite useable and recreates the sound of the DX7 with greater accuracy than any previous open-source emulation (that the author is aware of) It can easily load most of the thousands of DX7 patch bank files available on the Internet, and can accept patch editing commands via MIDI sys-ex messages from your favorite DX7 editor/librarian. hexter operates as a plugin for the DSSI Soft Synth Interface. DSSI is a plugin API for software instruments (soft synths) with user interfaces, permitting them to be hosted in-process by Linux audio applications. More information on DSSI can be found at: http://dssi.sourceforge.net/ The latest hexter version (currently 0.5.7) can be obtained at: http://sourceforge.net/project/showfiles.php? group_id=104230package_id=134428 hexter requires a working DSSI host, liblo, GTK+ 1.2.x, plus the ALSA headers and LADSPA SDK. hexter is written by Sean Bolton, and copyright (c)2004 under the GNU General Public License, version 2 or later. hexter benefited greatly from previous open-source efforts, most notably Juan Linietsky's rx-saturno, and FluidSynth by Peter Hanappe, et al.
Re: [linux-audio-dev] A statement regarding DSSI
On Sep 13, 2004, at 1:18 AM, Mario Lang wrote: I just took the time and looked at DSSI, and as far as I can see, it would solve most of the problems I am having regarding UIs. The OSC based UI-to-host communication concept nicely separates the actual UI from the DSP code and forces the developer to separate the GUI code from the actual backend. snip Thanks to those who work on DSSI, it looks very promising to me. You're most welcome. I hope you find it useful. Any early adopters yet? At the moment, hosts with DSSI support include: - Rosegarden-4, version 0.9.9 and later. - The example host in the DSSI distribution. DSSI plugins available are: - A FluidSynth wrapper plugin, also part of the DSSI distribution. - Xsynth-DSSI, a classic-analog style softsynth. - A VST wrapper plugin, allowing use of VST instruments and effects. - Two additional simple demonstration plugins in the DSSI distribution. References: http://dssi.sourceforge.net/ http://www.rosegardenmusic.com/ http://sourceforge.net/project/showfiles.php?group_id=104230 -- -Sean
