You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(24) |
Sep
(10) |
Oct
(125) |
Nov
(112) |
Dec
(33) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(41) |
Feb
(10) |
Mar
(18) |
Apr
(102) |
May
(54) |
Jun
(13) |
Jul
(21) |
Aug
(13) |
Sep
(10) |
Oct
(53) |
Nov
(45) |
Dec
(8) |
2006 |
Jan
(44) |
Feb
(13) |
Mar
(27) |
Apr
(3) |
May
|
Jun
(7) |
Jul
(4) |
Aug
(7) |
Sep
(3) |
Oct
(5) |
Nov
(8) |
Dec
(8) |
2007 |
Jan
(15) |
Feb
(7) |
Mar
(11) |
Apr
(6) |
May
(9) |
Jun
(2) |
Jul
(18) |
Aug
(18) |
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(5) |
Dec
(13) |
2009 |
Jan
(1) |
Feb
(9) |
Mar
(4) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
2010 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
(4) |
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
(2) |
Mar
(17) |
Apr
|
May
|
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(3) |
2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Sean B. <se...@sm...> - 2018-03-18 20:53:26
|
I'm pleased to announce the 1.1.0 release of hexter, a DSSI softsynth plugin that models the sound generation of a Yamaha DX7 synthesizer. This release provides support for DSSI hosts which don't support run_multiple_synths(), for example, Carla and Renoise. Each instance of the plugin is run separately, and support for the global polyphony limit has been removed. Several bugs and numerous compiler warnings have been fixed. Find hexter here: http://smbolton.com/hexter.html The distribution tarball is here: https://github.com/smbolton/hexter/releases/tag/version_1.1.0 More information on the DSSI plugin standard, available hosts and plugins can be found here: http://dssi.sourceforge.net/ hexter is written and copyright (c) 2018 by Sean Bolton, and licensed under the GNU General Public License, version 2 or later. Thanks to Andreas Müller for contributing a bug fix. Have fun! -Sean |
From: Sean B. <se...@sm...> - 2017-07-02 18:41:12
|
Hi Jamie, On Sun Jul 2 2017, Jamie Bullock wrote: > > On 1 Jul 2017, at 23:18, Sean Bolton <se...@sm...> wrote: > > > > I'm pleased to announce the 20170701 release of WhySynth, a DSSI > > softsynth plugin featuring four oscillators per voice, multiple > > oscillator, filter, and envelope modes, effects, and more. > > > > New since the last release: > > > > * Fixes for a couple security concerns, a pile of bugs, and a raft > > of compiler warnings. > > Out of interest what were the security issues? Heh, I guess that sounds a little pretentious, given the context. Buffer overflows: a maliciously-crafted patch file could cause the GUI to display garbage or crash. -Sean |
From: Jamie B. <ja...@ja...> - 2017-07-02 08:35:57
|
> On 1 Jul 2017, at 23:18, Sean Bolton <se...@sm...> wrote: > > I'm pleased to announce the 20170701 release of WhySynth, a DSSI > softsynth plugin featuring four oscillators per voice, multiple > oscillator, filter, and envelope modes, effects, and more. > > New since the last release: > > * Over 100 new patch presets, thanks to Brian Collins at > linuxsynths.com. > > * Patches now have a 'category' field, with which you can organize > the patch list. > > * Fixes for a couple security concerns, a pile of bugs, and a raft > of compiler warnings. Out of interest what were the security issues? Jamie |
From: Sean B. <se...@sm...> - 2017-07-01 22:41:37
|
I'm pleased to announce the 20170701 release of WhySynth, a DSSI softsynth plugin featuring four oscillators per voice, multiple oscillator, filter, and envelope modes, effects, and more. New since the last release: * Over 100 new patch presets, thanks to Brian Collins at linuxsynths.com. * Patches now have a 'category' field, with which you can organize the patch list. * Fixes for a couple security concerns, a pile of bugs, and a raft of compiler warnings. * A change to the default knob behavior. * No new synthesis features (yet). See below for information on potential breakage or confusion caused by these changes. Find WhySynth here: http://smbolton.com/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) 2017 by Sean Bolton, and licensed under the GNU General Public License, version 2. Oh, goody, breakage and confusion: * The addition of the category field meant a change to the patch file format. Unfortunately, earlier versions of WhySynth were not designed with forward compatibility in mind. If you save patches in the new 'version 1' format, older WhySynths will not be able to load them. If you save patches in the old 'version 0' format, both older and current versions of WhySynth can use them. (Current versions can even save and load the categories using 'version 0' format, thanks to a bit of a hack, but don't round-trip from new to old to new versions of WhySynth, or you'll lose your categories.) * This release changes the default mouse button bindings of the knobs. Previously, dragging mouse button 1 made changes in angular mode: the knob would (quite abruptly) move to point toward the mouse pointer. Dragging mouse button 3 used to operate in linear mode, where moving the pointer vertically or horizontally would make smooth incremental changes. This release swaps that behavior between the two buttons, to what I think is a more usable default. If you prefer the old behavior, you can add the following to your ~/.gtkrc-2.0: gtk-control-rotary-prefer-angular = 1 Have fun! -Sean |
From: Gordonjcp <gor...@gj...> - 2016-02-15 09:40:47
|
On Mon, Feb 15, 2016 at 07:37:23AM +0100, Frank Schäfer wrote: > Hello guys, > > I'm trying to download the DSSI packages from sourceforge. > ALL of the packages open the download for Hexter tough. > > I'm doing this because I want to try out Wsynth from your site. > > The Wsynth installation from my distro (Ubuntu 14.04) has a little problem: > I can save banks but if I try to load the bank an eror message comes up saying no bank was recognised in the file. > This saying I cannot save my work and have to start up from scratch every time I open the synth. > > Please advise how to get OTHER packages than hexter fron DSSI or how to circumvent the error. > > Thanks a lot > > Cheers > Frank Wow, Wsynth is a blast from the past. I think there was a bug in the bank loading code. Maybe you could grab a copy of the source with "apt-get source wsynth-dssi" and seeing what upsets the patch loading code, or even just bodge them into the plugin's startup code. I've not worked on Wsynth for a long time and no longer have any computers set up for audio work. -- Gordonjcp MM0YEQ |
From: Frank S. <fra...@ce...> - 2016-02-15 06:37:32
|
Hello guys, I'm trying to download the DSSI packages from sourceforge. ALL of the packages open the download for Hexter tough. I'm doing this because I want to try out Wsynth from your site. The Wsynth installation from my distro (Ubuntu 14.04) has a little problem: I can save banks but if I try to load the bank an eror message comes up saying no bank was recognised in the file. This saying I cannot save my work and have to start up from scratch every time I open the synth. Please advise how to get OTHER packages than hexter fron DSSI or how to circumvent the error. Thanks a lot Cheers Frank |
From: Frank N. <bea...@we...> - 2015-01-31 12:21:10
|
[Sorry for cross-posting, please distribute.] The Linux Audio Conference submissions deadline has been extended for another week! Please note the new deadline: Sunday, Feb 8th, 2015 (23:59 HAST) So, if you were considering to submit a paper but couldn't make up your mind yet, here is your chance to become active! Never forget that this conference lives through the people participating in it. February 8th is the new deadline for all submission types: papers, music, installations, workshop proposals. Check out the link below for more info: http://lac.linuxaudio.org/2015/participation Note that as usual we have created two different OpenConf instances: one for the submission of regular papers, lightning talks and poster sessions, and a second one for music, installations and workshop proposals. For the latter, please also check the detailed instructions at http://lac.linuxaudio.org/2015/download/lac2015-call-for-miw.pdf. If you have any questions concerning your submission, please don't hesitate to contact us at la...@li..., or through our #lac2015 IRC channel on freenode.net. Please spread this information to anyone who might be interested. We look forward to your submissions and hope to meet you in Mainz in April! Sincerely, The LAC 2015 Organizing Team |
From: Frank N. <bea...@we...> - 2015-01-03 15:36:32
|
[Sorry for cross-posting, please distribute.] Linux Audio Conference 2015 - Call for Participation (Due to exceptional circumstances, this announcement comes a bit late, so please note the early deadline of Feb 1st for submissions. We apologize.) We are happy to announce the next issue of the Linux Audio Conference (LAC), April 9-12, 2015 @ JGU | Johannes Gutenberg University, in Mainz, Germany. http://lac.linuxaudio.org/2015/ The Linux Audio Conference is an international conference that brings together musicians, sound artists, software developers and researchers, working with Linux as an open, stable, professional platform for audio and media research and music production. LAC includes paper sessions, workshops, and a diverse program of electronic music. *Call for Papers, Workshops, Music and Installations* We invite submissions of papers addressing all areas of audio processing and media creation based on Linux and other open source software. Papers can focus on technical, artistic and scientific issues and should target developers or users. In our call for music, we are looking for works that have been produced or composed entirely/mostly using Linux and other open source music software. The online submission of papers, workshops, music and installations is now open at http://lac.linuxaudio.org/2015/participation The deadline for all submissions is Feb 1st, 2015 (23:59 HAST). You are invited to register for participation on our conference website. There you will find up-to-date instructions, as well as important information about dates, travel, lodging, and so on. This year's conference is hosted by the Computer Music Research Group (Bereich Musikinformatik) at the IKM (Institut für Kunstgeschichte und Musikwissenschaft) of the Johannes Gutenberg University (JGU) at Mainz. Being founded in 1991, our research group has been among the first German academic institutions in this interdisciplinary field at the intersection of music, mathematics, computer science and media technology. In our media lab students are working almost exclusively with Linux, and in our research we are also devoted to contributing to the growing body of open source audio and computer music software. http://www.musikwissenschaft.uni-mainz.de/Musikinformatik/ We look forward to your submissions and hope to meet you in Mainz in April! Sincerely, The LAC 2015 Organizing Team |
From: Jeffrey H. <jhu...@ya...> - 2013-03-18 00:54:46
|
http://www.corn-island-marinaresort.es/fqx/xycdzxjs |
From: Sean B. <se...@sm...> - 2012-12-27 23:25:58
|
Hi all, On Mon Dec 10 2012, Sean Bolton wrote: > SourceForge is asking us to upgrade the DSSI project to their new > Allura platform.... Done. My experience with the new platform has been much like the old Sourceforge: awkward interface, scant or hard-to-locate documentation, but it basic works much like the old one. > but some external links to the > repo, email archives, and downloads will need to be fixed. I actually didn't see anything break on the DSSI site or my own. Really old URLs of the form: http://sourceforge.net/project/showfiles.php?group_id=104230&package_id=127571 will need to be fixed, but SF has been deprecating them for years. > SF is also encouraging us to migrate from CVS to a different SCM (SVN, > git or Mercurial ... Migrated to git, using cvs2svn [1], keeping commit history and tags (there were no branches.) We had six modules in CVS: dssi, dssi-vst, dssi-website, fluidsynth-dssi, hexter, and xsynth-dssi. I've moved hexter to github, and Chris moved dssi-vst to his breakfastquay.com, leaving four modules to convert. Due to the awkward way each new repo shows up in the summary page 'top menu', I ended up calling them 'Git: DSSI', 'Git: Website', 'Git: FluidSynth-DSSI', and 'Git: Xsynth-DSSI'. Kind of ugly, but the only alternative seems to be subprojects, which seems even less attractive. Let me know if you have any questions. -Sean [1] cvs2svn: http://cvs2svn.tigris.org/ The best description I found of how to use it with SourceForge: http://sourceforge.net/u/earnie/home/CVS%20to%20Git%20SF%20repository/ |
From: Chris C. <ca...@al...> - 2012-12-11 10:29:41
|
On 10 December 2012 21:02, Sean Bolton <se...@sm...> wrote: > otherwise, I'll do it in a few days. Fine by me. > SF is also encouraging us to migrate from CVS to a different SCM (SVN, > git or Mercurial; see IRC log below). I'd be happy to migrate each DSSI > subproject to git (keeping full commit history) the next time I have > something to commit, if you all are supportive of that and/or don't > speak up with any objections. Also OK with me. My preferred system is Mercurial (dssi-vst is in Mercurial, see https://code.breakfastquay.com/projects/dssi-vst) but I can cope with git, especially if someone else is doing the work! Any of them is better than CVS, anyway. Chris |
From: Sean B. <se...@sm...> - 2012-12-10 21:56:28
|
Hi all, SourceForge is asking us to upgrade the DSSI project to their new Allura platform (see email below). Sounds like mostly a no-brainer, the existing CVS will remain as is, but some external links to the repo, email archives, and downloads will need to be fixed. If you have any concerns regarding the upgrade, let me know, otherwise, I'll do it in a few days. SF is also encouraging us to migrate from CVS to a different SCM (SVN, git or Mercurial; see IRC log below). I'd be happy to migrate each DSSI subproject to git (keeping full commit history) the next time I have something to commit, if you all are supportive of that and/or don't speak up with any objections. Let me know what you think. Thanks, -Sean Begin forwarded message: Date: Mon, 10 Dec 2012 10:47:51 -0500 From: "Rich Bowen" To: "Sean Bolton", "Chris Cannam", "Steve Harris" Subject: DSSI, it's time to upgrade your classic SourceForge project Dear DSSI project admin, Since your project has shown some activity in the last few months, we want to be sure that you're aware that some changes are happening at SourceForge, and we want to be sure you're not caught by surprise. As you may already be aware, SourceForge is upgrading to a new platform (code-named Allura), and as a result, we'll be retiring the Classic SourceForge platform, which your project is still using. Our goal is to have everybody off of the old platform in the first quarter of next year, so that we can retire that code and focus our attention on the new platform. It would, of course, be preferable if you migrate your own project in your own time. You can read more about the new platform at https://sourceforge.net/p/upgrade/ and then, when you're ready, press the Upgrade button next to your project name. If you have any concerns about the process, or if your project has an unusually large number of forums, source code repositories, or trackers, please don't hesitate to contact us to discuss your upgrade. It's important to us that it go smoothly. As always, thanks for being part of the SourceForge community. Rich Bowen SourceForge Community Manager rb...@so... Begin freenode #sourceforge IRC log 2012/12/10: [12:22] <gribble> What smbolton meant to say was: Hi- We've been asked to upgrade our project (DSSI) to the new Allura platform, and I'm having trouble finding information on what will happen to our existing CVS when I hit the big 'Upgrade' button. [12:23] <@ctsai-sf> Unlike repo types fully supported on the new platform (svn, git, hg), essentially nothing. We create a new info page for CVS, but otherwise just point to the same old repo and code browser. [12:24] <@ctsai-sf> That said, I highly recommend that you consider migrating to a different SCM. Among other reasons, due to some low level limitations with CVS, there are multiple single points of failure for CVS hosting that aren't an issue with other SCMs. [12:25] <@ctsai-sf> So, we can't really provide the same level of availability for CVS as we can for other SCMs. |
From: Steve H. <S.W...@ec...> - 2012-11-02 18:35:32
|
Not sure this reached the list. Begin forwarded message: > From: dss...@li... > Subject: Auto-discard notification > Date: 1 November 2012 22:05:40 GMT > To: dss...@li... > > The attached message has been automatically discarded. > From: Jamie Bullock <ja...@ja...> > Subject: Re: [DSSI] hexter turns 1.0.0 > Date: 1 November 2012 21:42:11 GMT > To: Sean Bolton <se...@sm...> > Cc: DSSI-Devel <dss...@li...> > > > > Congratulations Sean. It's fantastic you're still working on this. > > If it's any further incentive, Hexter was used in a performance of Madonna of Winter and Spring by Jonathan Harvey in January this year. The piece was performed at the Barbican Centre in London and broadcast worldwide on BBC Radio 3. Hexter was used to emulate a TX816, which is heard very clearly throughout. > > http://www.barbican.org.uk/music/event-detail.asp?ID=11882 > > All best, > > Jamie > > On 1 Nov 2012, at 16:17, Sean Bolton <se...@sm...> wrote: > >> It's hard to believe eight years have gone by since I first released >> hexter. Since it now has the integrated patch editor that I always >> felt it needed, I'm calling the latest release 1.0.0: >> >> http://sourceforge.net/projects/dssi/files/hexter/1.0.0/ >> >> hexter is a software synthesizer that models the sound generation of >> a Yamaha DX7 synthesizer. It can easily load most DX7 patch bank >> files, edit those patches via a built-in editor or MIDI sys-ex >> messages, and recreate the sound of the DX7 with greater accuracy >> than any previous open-source emulation (that the author is aware >> of...) hexter operates as a plugin for the DSSI Soft Synth >> Interface. >> >> Release 1.0.0 adds significant capability to hexter over the 0.6.2 >> release, including: >> >> * An integrated patch editor (finally!) >> >> * The option to use floating-point math in the synthesis code >> instead of fixed-point. >> >> * Performance optimizations. >> >> * Better patch bank loading, thanks to Martin Tarenskeen. >> >> * MIDI non-registered parameter (NRPN) support, thanks to Jamie >> Bullock. >> >> hexter is written and copyright (c) 2012 by Sean Bolton, and >> licensed under the GNU General Public License, version 2 or later. >> >> More information about hexter and DSSI can be found at: >> >> http://dssi.sourceforge.net/hexter.html >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_sfd2d_oct >> _______________________________________________ >> DSSI-devel mailing list >> DSS...@li... >> https://lists.sourceforge.net/lists/listinfo/dssi-devel > > > > |
From: Sean B. <se...@sm...> - 2012-11-01 16:43:51
|
It's hard to believe eight years have gone by since I first released hexter. Since it now has the integrated patch editor that I always felt it needed, I'm calling the latest release 1.0.0: http://sourceforge.net/projects/dssi/files/hexter/1.0.0/ hexter is a software synthesizer that models the sound generation of a Yamaha DX7 synthesizer. It can easily load most DX7 patch bank files, edit those patches via a built-in editor or MIDI sys-ex messages, and recreate the sound of the DX7 with greater accuracy than any previous open-source emulation (that the author is aware of...) hexter operates as a plugin for the DSSI Soft Synth Interface. Release 1.0.0 adds significant capability to hexter over the 0.6.2 release, including: * An integrated patch editor (finally!) * The option to use floating-point math in the synthesis code instead of fixed-point. * Performance optimizations. * Better patch bank loading, thanks to Martin Tarenskeen. * MIDI non-registered parameter (NRPN) support, thanks to Jamie Bullock. hexter is written and copyright (c) 2012 by Sean Bolton, and licensed under the GNU General Public License, version 2 or later. More information about hexter and DSSI can be found at: http://dssi.sourceforge.net/hexter.html |
From: Sean B. <se...@sm...> - 2012-09-04 16:33:41
|
I'm pleased to announce the 20120903 release of WhySynth, a DSSI softsynth plugin. New since my last release announcement: * One new oscillator mode (Wavecycle Chorus) and four new filter modes (resonz, high-pass and band-reject, with thanks to Luke Andrew). * Some new patches. * An icon for desktop use. * A bug fix for an ugly click that would occur when using portamento in monophonic mode. * WhySynth development is now hosted on Github. Find WhySynth here: http://smbolton.com/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) 2012 by Sean Bolton, under the GNU General Public License, version 2. |
From: Jeffrey H. <jhu...@ya...> - 2012-07-01 01:57:05
|
>Cool. Let me know when it's released, and I'll update the DSSI website. I turned it around a bit quicker than anticipated, you can go ahead and update the site. It's now released as part of my LMS Plugin Suite 12.06-2 here: http://sourceforge.net/projects/libmodsynth/files/plugins/ The .deb or source packages install the sampler plugin which is called Euphoria. The current feature list: 1. Loads up to 32 samples 2. Up to 120 note polyphony, and up to 32 samples per voice. 3. Support for mapping samples by pitch, including layering samples 4. Polyphonic effects: multimode filter, distortion, white_noise 5. Sample graph, including visually setting sample start/end points 6. Support for saving instruments to a text file using relative or absolute file paths (you must run the 'copy files to single directory' menu action to use relative paths) 7. Modulation: ADSR for amplitude, ADSR for filter, LFO that can modulate filter cutoff, pitch or amplitude, ramp envelope for pitch, glide, pitchbend In the future I'm going to add better interpolation, modular polyphonic effects, effect groups, velocity mapping, sample looping and other features. Thanks, Jeff |
From: Jeffrey H. <jhu...@ya...> - 2012-06-30 01:03:37
|
Thanks Sean, that worked, no more pitch artifacts when pitchbending/gliding. I also fixed the only other major outstanding bug tonight, so I'll probably release it this weekend if I don't find any other bugs. Thanks again. |
From: Jeffrey H. <jhu...@ya...> - 2012-06-29 23:09:07
|
I'll try to come up a detailed analysis of the problem tonight or no later than tomorrow night if I can. I'll also try to get to the bottom of what Muse2 is actually doing that Rosegarden/others aren't. I wouldn't delay the Muse2 release over it though, I assume that after 2.0, you'll start working on 2.1 or 2.0.1, I don't see any reason why this can't wait until the next maintenance release. While I'm working on that, is it possible that configure() values are being truncated to a very low char count? I verfied in my Muse2 project file that the configure key/value was being stored correctly, but the mis-behavior could be adequately explained by the char* being sent to the GUI being truncated by Muse2. I'm sending a quite large configure value, anywhere from 32 bytes to as much as a few kilobytes. Thanks, Jeff |
From: Jeffrey H. <jhu...@ya...> - 2012-06-29 01:29:12
|
>Cool. Let me know when it's released, and I'll update the DSSI website. Will do. Probably the certified 1.0 gold stable release will be by the end of next month, depending on how long it takes me to iron out these last few bugs, mostly with the pitchbend/glide artifacts. >I couldn't find a clear example to point you toward, since they all >used optimizations that make it more difficult to see what they're >really doing. I've attached a very simple example (untested, but I >think it's correct). Thanks, I think that's enough to get me going. |
From: Jeffrey H. <jhu...@ya...> - 2012-06-28 02:03:38
|
Hello, I've been working on a full-featured sampler that's forked from Trivial_Sampler. It's called Euphoria, if you'd like to check it out, I'd recommend getting the latest Git/Master from here: git clone git://git.code.sf.net/p/libmodsynth/git libmodsynth-git I'm a little unclear on how the sample interpolation works, any guidance is greatly appreciated: 1. In the 'addSample' function in synth.c; I'm having a hard time wrapping my head around how the sample position to interpolate from is being determined, especially the meaning of this part: float rs = s * ratio; unsigned long rsi = lrintf(floor(rs)); The problem I'm having is that when I attempt to modify the pitch by pitchbend or glide I'm getting a lot of artifacts, presumably because changing ratio (by modifying the value of n) has an adverse effect on the values of rs and rsi, leading to interpolating the wrong samples. Also, I intend to implement SINC interpolation at some point, and it would help to have a better understanding of the current interpolation mechanism. Thanks, Jeff |
From: Jeffrey H. <jhu...@ya...> - 2012-03-27 12:23:32
|
Makes sense. Thanks Sean. |
From: Sean B. <smb...@jp...> - 2012-03-27 03:25:24
|
Hi Jeff, On Mon, 26 Mar 2012 17:19:53 -0700 (PDT) Jeffrey Hubbard <jhu...@ya...> wrote: > The GUI binary, called "LMS_qt" in all of my plugins, only works if > the plugin's label is "LMS". Changing the name of the outputted > binary in the > > Makefile requires changing the label, but it only works if the binary > is named [label]_qt. > > Is this by design, or is it a bug? Design. Remember that one shared object (.so) can contain multiple different plugins, so the correspondence between the label and the base of the GUI binary's filename is needed, so the host can load the correct GUI for the plugin. If that's not clear, review the DSSI doc/RFC.txt section on 'Discovery and Startup'. Have fun, -Sean |
From: Jeffrey H. <jhu...@ya...> - 2012-03-27 00:20:00
|
I did some digging, and I think I determined what the OSC part is looking for. The GUI binary, called "LMS_qt" in all of my plugins, only works if the plugin's label is "LMS". Changing the name of the outputted binary in the Makefile requires changing the label, but it only works if the binary is named [label]_qt. Is this by design, or is it a bug? ________________________________ From: Jeffrey Hubbard <jhu...@ya...> To: Sean Bolton <smb...@jp...> Cc: "DSS...@li..." <DSS...@li...> Sent: Sunday, March 25, 2012 11:15 PM Subject: Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:" I have nowimplementedthe following: 1. Root-less debugging and deb packaging (it turns out that I needed to use system("export DSSI_PATH=/a/b/c ; jack-dssi-host plugin.so"); in a single call , I was exporting in a separate system call, that doesn't work)) 2. Switches to input user options into any of the commands that perform a make install. Also a --no-sudo switch for installs. 3. The packaging system offers to install dependencies one time only, with a default answer of "no". I've dropped the audio group add altogether, except for suggesting that the user may wish to do so. However, for some reason, setting LASPA_Descriptor->Label to "LMS" works, but setting it to something like "RAYV" causes jack-dssi-hostto hang on this line: osc.udp://bulldozer:18542/dssi//usr/local/lib/dssi/ray_v/RAYV/chan00 I recall going through something similar when I was forking Ray-V from Less_Trivial_Synth, and that label was set to "LTS". I did try a reboot inbetween compiling to make sure it wasn't an OSC/networking issue. I also looked in ladspa.h, but I didn't see any guidelines for how a label should be, except that it shouldn't contain whitespace. As for your other suggestions: 1. checkinstall: I'm in the process of deprecating it in favor of native packaging like what's already in plugins/build-all.pl.2. I'll continue to work on my autotool-ing. Unfortunately, my prior knowledge of autotools before this project was limited to "./configure ; make ; sudo make install", and clearly there's still room for improvement :) 3. "maybe it makes more sense for your app to concentrate on designing plugins and hosting them in-app." Actually, I think my intentions with the designer may be a little different than what you were thinking. I wasn't going to make a traditional, full-blown designer like Native Instruments Reaktor where the designer is hosting the instrument and constantly dynamically re-compiling. My designer concept is going to be very simple and limited. The UI designer will offer very few choices for how to do anything, and the audio back-end will only allow dropping in LMS audio modules in a well-defined order, and then only basic options for connecting them to each other and the UI. I think the "less-is-more" concept gives the best of both worlds: Non-programmers will have an even easier tool to create simple plugins with, with a more structured workflow and less potential to screw something up, and advanced programmer types can quickly design their idea visually, then export to C/C++ code to tweak as much as they want. There's also the added benefit that a simple designer that spits out C/C++ into a basic template is also exponentially easier for me to develop in only a month or two than a full-service designer like SynthEdit or Reaktor that could take me years to develop. Thanks, Jeff |
From: Jeffrey H. <jhu...@ya...> - 2012-03-26 03:15:14
|
I have nowimplementedthe following: 1. Root-less debugging and deb packaging (it turns out that I needed to use system("export DSSI_PATH=/a/b/c ; jack-dssi-host plugin.so"); in a single call , I was exporting in a separate system call, that doesn't work)) 2. Switches to input user options into any of the commands that perform a make install. Also a --no-sudo switch for installs. 3. The packaging system offers to install dependencies one time only, with a default answer of "no". I've dropped the audio group add altogether, except for suggesting that the user may wish to do so. However, for some reason, setting LASPA_Descriptor->Label to "LMS" works, but setting it to something like "RAYV" causes jack-dssi-hostto hang on this line: osc.udp://bulldozer:18542/dssi//usr/local/lib/dssi/ray_v/RAYV/chan00 I recall going through something similar when I was forking Ray-V from Less_Trivial_Synth, and that label was set to "LTS". I did try a reboot inbetween compiling to make sure it wasn't an OSC/networking issue. I also looked in ladspa.h, but I didn't see any guidelines for how a label should be, except that it shouldn't contain whitespace. As for your other suggestions: 1. checkinstall: I'm in the process of deprecating it in favor of native packaging like what's already in plugins/build-all.pl.2. I'll continue to work on my autotool-ing. Unfortunately, my prior knowledge of autotools before this project was limited to "./configure ; make ; sudo make install", and clearly there's still room for improvement :) 3. "maybe it makes more sense for your app to concentrate on designing plugins and hosting them in-app." Actually, I think my intentions with the designer may be a little different than what you were thinking. I wasn't going to make a traditional, full-blown designer like Native Instruments Reaktor where the designer is hosting the instrument and constantly dynamically re-compiling. My designer concept is going to be very simple and limited. The UI designer will offer very few choices for how to do anything, and the audio back-end will only allow dropping in LMS audio modules in a well-defined order, and then only basic options for connecting them to each other and the UI. I think the "less-is-more" concept gives the best of both worlds: Non-programmers will have an even easier tool to create simple plugins with, with a more structured workflow and less potential to screw something up, and advanced programmer types can quickly design their idea visually, then export to C/C++ code to tweak as much as they want. There's also the added benefit that a simple designer that spits out C/C++ into a basic template is also exponentially easier for me to develop in only a month or two than a full-service designer like SynthEdit or Reaktor that could take me years to develop. Thanks, Jeff |
From: Sean B. <smb...@jp...> - 2012-03-25 16:38:08
|
Hi Jeff, On Sun, 25 Mar 2012 05:37:59 -0700 (PDT) Jeffrey Hubbard <jhu...@ya...> wrote: > Ray-V is meant to be a good > starting point for others to write synths, so it only makes sense to > start off with a simple synth, and keep it simple. Way-V will be the > flagship synthesizer with multiple tab pages full of knobs and way > too many choices ;) Cool, just like Xsynth-DSSI is my simple example, and WhySynth is my flagship. People do keep asking for new features in Xsynth-DSSI, though.... I'm looking forward to checking out Way-V. > 3. Root, etc... Perhaps you can answer a question for me, I > actually attempted to go root-less yesterday, but jack-dssi-host > refused to acknowledge any plugins not in /usr/lib/dssi > or /usr/local/lib. I suppose ~/.dssi might work, but I didn't try > that yet because I wanted to keep it in the project folder. I tried > setting the DSSI_PATH environment variable, but that didn't work > either. Setting DSSI_PATH should work. With bash, you do either: $ export DSSI_PATH=/path/to/plugin $ jack-dssi-host plugin.so or $ DSSI_PATH=/path/to/plugin jack-dssi-host plugin.so If you're using exec() or system() from perl, use the second form, or set DSSI_PATH in %ENV beforehand. > I don't know how normal people handle things like packaging, > dependencies, etc... So I'm more than open to suggestions from more > experienced developers like yourself. Some thoughts come to mind: - Use generic tools (e.g. autoconf) rather than distribution-specific tools (e.g. checkinstall), so your code works on the widest practical range of systems. - Leverage as much as possible the existing capabilities of autotools (or waf, scons, etc.) to find dependencies, create makefiles, and manage building and installing -- so you can concentrate on creating the functionality that is unique to your project. - Autotools will build for the widest variety of systems, but it's considerably slower than e.g. cmake or waf. - Decide how much effort you want to put in to the packaging aspect. I mean, maybe it makes more sense for your app to concentrate on designing plugins and hosting them in-app. Then offer some simple options to export a plugin: create a .deb, install to staging directory (DESTDIR), or install to live filesystem (only this last one should need root privileges.) Hope that's useful, -Sean |