dssi-devel

[DSSI] Request to have my project added to your list of "Currently available plugins include:"

[Jeffrey H. <jhu...@ya...>]

Hello,

If you don't mind, I would like to have my DSSI plugins added to the list on your sourceforge page.  I currently have 5 plugins available they are:

Ray-V (analog-style lead synthesizer)
LMS Filter (multimode filter)
LMS Delay (delay with ping-pong and ducking)
LMS Comb (Comb filter)
LMS Distortion (hard-clipping distortion)

(or just collectively, the LibModSynth Plugin Suite)

...I also have 3 more with an imminent release, at which point the suite will be 8 plugins strong.


Here is my project page:

http://sourceforge.net/projects/libmodsynth/

Screenshots of the plugins:

http://libmodsynth.sourceforge.net/index.php?page=gallery

An example of what my early adopters are saying:

http://linuxmusicians.com/viewtopic.php?f=1&t=7834&sid=58f120b07bcf9bbf854649d0a5f72ee4


The project itself, called LibModSynth, is a C audio-DSP library and set of developer tools for developing DSSI plugins with Qt GUIs.  However, I'm not yet promoting the developer parts too heavily just yet, because the API is still changing, and is not yet feature-complete.  


Thanks,
Jeff

Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"

[Sean B. <smb...@jp...>]

On Fri, 16 Mar 2012 19:08:37 -0700 (PDT)
Jeffrey Hubbard <jhu...@ya...> wrote:
> If you don't mind, I would like to have my DSSI plugins added to the
> list on your sourceforge page.  I currently have 5 plugins available
[snip] 
> Here is my project page:
> 
> http://sourceforge.net/projects/libmodsynth/

Hi Jeffery -- looks interesting.  Hopefully I can get the webpage
updated with a link to your project on Tuesday. 

Is there a reason why you include dssi.h and jack-dssi-host in your
source tree, rather than expect the user to have them installed (as
would be the norm with most distributions)?

Thanks,

-Sean

Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"

[Jeffrey H. <jhu...@ya...>]

Hi Sean,

Both of those are legacy components from the DSSI distribution whose fate is still undetermined.  I should mention that the project was only founded around the mid January 2012, the library and dev tools are still in alpha...  There's still more cleanup and polishing to do before I make an official release of the developer bits.


dssi.h is a remnant of when I first forked Less_Trivial_Synth into Ray-V, which was then eventually forked into the other 4 plugins.  The DSSI distribution had it in it's own dssi.h, and I copied it to each plugin's own folder.  I do have the dssi-dev package included as a dependency for the automatic dependency installation that my build script does for for Ubuntu users, but for now I was leaving it in there for the benefit of people using other distros.  Whenever I get around to properly supporting the other major distros with my build script, I intend to take it out.

As far as jack-dssi-host, the build script (build.pl in the plugin folders) is dynamically compiling it and using it for console debugging.  Also, I'm moving to a system (that pseudo-functional build-all.pl file) that will package every plugin in the LibModSynth directory into a single .deb (and eventually a .rpm), and I'm considering including my own lms-jack-dssi-host in the .deb package.  I was considering forking jack-dssi-host, so that one will likely stay in some form.

Thanks,
Jeff



________________________________
 From: Sean Bolton <smb...@jp...>
To: Jeffrey Hubbard <jhu...@ya...> 
Cc: "DSS...@li..." <DSS...@li...> 
Sent: Sunday, March 18, 2012 10:57 PM
Subject: Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"
 
On Fri, 16 Mar 2012 19:08:37 -0700 (PDT)
Jeffrey Hubbard <jhu...@ya...> wrote:
> If you don't mind, I would like to have my DSSI plugins added to the
> list on your sourceforge page.  I currently have 5 plugins available
[snip] 
> Here is my project page:
> 
> http://sourceforge.net/projects/libmodsynth/

Hi Jeffery -- looks interesting.  Hopefully I can get the webpage
updated with a link to your project on Tuesday. 

Is there a reason why you include dssi.h and jack-dssi-host in your
source tree, rather than expect the user to have them installed (as
would be the norm with most distributions)?

Thanks,

-Sean

Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"

[Jamie B. <ja...@po...>]

Hi Jeffrey,

This looks like an interesting project. Would you be able to say a little bit about the advantages of libmodsynth over writing DSSI wrappers around something like STK (https://ccrma.stanford.edu/software/stk/), or creating UI's for existing LADSPA plugins?

best,

Jamie


--
http://www.jamiebullock.com



On 17 Mar 2012, at 02:08, Jeffrey Hubbard wrote:

> Hello,
> 
> If you don't mind, I would like to have my DSSI plugins added to the list on your sourceforge page.  I currently have 5 plugins available they are:
> 
> Ray-V (analog-style lead synthesizer)
> LMS Filter (multimode filter)
> LMS Delay (delay with ping-pong and ducking)
> LMS Comb (Comb filter)
> LMS Distortion (hard-clipping distortion)
> 
> (or just collectively, the LibModSynth Plugin Suite)
> 
> ...I also have 3 more with an imminent release, at which point the suite will be 8 plugins strong.
> 
> 
> Here is my project page:
> 
> http://sourceforge.net/projects/libmodsynth/
> 
> Screenshots of the plugins:
> 
> http://libmodsynth.sourceforge.net/index.php?page=gallery
> 
> An example of what my early adopters are saying:
> 
> http://linuxmusicians.com/viewtopic.php?f=1&t=7834&sid=58f120b07bcf9bbf854649d0a5f72ee4
> 
> 
> The project itself, called LibModSynth, is a C audio-DSP library and set of developer tools for developing DSSI plugins with Qt GUIs.  However, I'm not yet promoting the developer parts too heavily just yet, because the API is still changing, and is not yet feature-complete.  
> 
> 
> Thanks,
> Jeff
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> DSSI-devel mailing list
> DSS...@li...
> https://lists.sourceforge.net/lists/listinfo/dssi-devel

Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"

[Jeffrey H. <jhu...@ya...>]

Hi Jamie,

To be honest, I'd never heard of STK until now.  I have no practical experience with it, so I can't really say anything good or bad about their implementation, but I can detail mine:

1.  The audio DSP part of LibModSynth is written in C, instead of C++.  IMHO, C++ is not the best tool for the low level performance-critical bits(but then again, I'm not a big fan of C++ anyways, so I might just be biased).
2.  LibModSynth offers some exceptionally fast DSP math tailored specifically for audio.  The speed comes from plotting audio math that uses expensive functions like division, sin, cos, sinc, etc... into tables, and using cheap linear interpolation to approximate the results.  The tables were all carefully designed with just enough resolution to keep any artifacts from approximating the functions inaudible, but as small as possible to fit in CPU cache.  The included modules also use best practices in regards to not using division whenever possible, but rather calculating a reciprocal and multiplying instead.
3.  Eventually, I intend to create a visual plugin designer, where users can drag-n-drop components to build a plugin.  The killer feature of mine is that it will auto-generate a real C/C++ project folder from the visual design part.  The overall layout of the project files and UI design is all aimed at eventually being able to be auto-generated by a script, from an XML file.  This is also where all of my automatic compile/debug/packaging system is eventually heading.
4.  LibModSynth contains a selection of oscillators, filters, etc...  all designed for interoperability, performance and sound quality.
5.  The library parts are source based, instead of being a shared library.  This allows inlining of functions, as well as allowing developers to fork individual modules for each plugin.  This also provides greater performance from avoiding the overhead of calling functions from a shared library.

Thanks,
Jeff




________________________________
 From: Jamie Bullock <ja...@po...>
To: Jeffrey Hubbard <jhu...@ya...> 
Cc: "DSS...@li..." <DSS...@li...> 
Sent: Monday, March 19, 2012 6:50 AM
Subject: Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"
 

Hi Jeffrey,

This looks like an interesting project. Would you be able to say a little bit about the advantages of libmodsynth over writing DSSI wrappers around something like STK (https://ccrma.stanford.edu/software/stk/), or creating UI's for existing LADSPA plugins?

best,

Jamie


--
http://www.jamiebullock.com



On 17 Mar 2012, at 02:08, Jeffrey Hubbard wrote:

> Hello,
> 
> If you don't mind, I would like to have my DSSI plugins added to the list on your sourceforge page.  I currently have 5 plugins available they are:
> 
> Ray-V (analog-style lead synthesizer)
> LMS Filter (multimode filter)
> LMS Delay (delay with ping-pong and ducking)
> LMS Comb (Comb filter)
> LMS Distortion (hard-clipping distortion)
> 
> (or just collectively, the LibModSynth Plugin Suite)
> 
> ...I also have 3 more with an imminent release, at which point the suite will be 8 plugins strong.
> 
> 
> Here is my project page:
> 
> http://sourceforge.net/projects/libmodsynth/
> 
> Screenshots of the plugins:
> 
> http://libmodsynth.sourceforge.net/index.php?page=gallery
> 
> An example of what my early adopters are saying:
> 
> http://linuxmusicians.com/viewtopic.php?f=1&t=7834&sid=58f120b07bcf9bbf854649d0a5f72ee4
> 
> 
> The project itself, called LibModSynth, is a C audio-DSP library and set of developer tools for developing DSSI plugins with Qt GUIs.  However, I'm not yet promoting the developer parts too heavily just yet, because the API is still changing, and is not yet feature-complete.  
> 
> 
> Thanks,
> Jeff
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> DSSI-devel mailing list
> DSS...@li...
> https://lists.sourceforge.net/lists/listinfo/dssi-devel

Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"

[Jeffrey H. <jhu...@ya...>]

I was intrigued by STK, so I perused the source code to see if any the code could be translated to C and re-used in LibModSynth, and I think I can provide a better differentiation of LMS vs. STK now.


part 2:

1.  STK doesn't appear to be providing a complete implementation of all of it's modules, but more of just a starting point in many instances.  LibModSynth modules are more complete and ready-to-use in an actual plugin.
2.  STK doesn't have any of the more advanced performance optimizations that LMS has, for example:

      p_ = Stk::sampleRate() / frequency;    
//It should be using the reciprocal of the sample rate and then multiplying, it would be about 10x faster
      C2_ = 1 / p_;   
//Once again, not the way to calculate something that could happen once per-tick of the sample rate clock.
      rate_ = PI * C2_; 
      this->updateHarmonics();

Also, the use of switch statements instead of function pointers seems to be prevalent, that's not going to make for very fast code unless the compiler can figure out a way to make it into a function pointer.
STK also uses standard math libraries, the use of math.h/cmath/whatever functions won't be nearly as fast as LMS' math library functions using table lookups.


3.  LibModSynth allows for easy forking with a single command, and there is a work-in-progress script for generating a new empty plugin.  This gives developers a functional template to use as a starting point.

4.  Memory management:  LMS avoids reinstantiaing the same variables over and over again, like iterators.  All variables of known size are declared in the type they'll be used with.

STK example code:

      for (i=99; i>=0; i--) {
        fmGains_[i] = temp;
        temp *= 0.933033;
      }


LMS example code:

    typedef struct st_some_oscillator{
    //stuff
    int iterator;
    }

    osc->iterator = 0;

    while((osc->iterator) < 100){
    //do something with osc
    osc->iterator = (osc->iterator) + 1;

This avoids allocating and freeing new stack memory constantly, and keeps everything allocated a single time on the heap for the lifetime of the plugin.  Of course, the compiler might figure out some of these optimizations for you, but I don't leave it to chance.



Overall though, I think my optimized DSP strategy has already proven it's worth, a Ray-V(my plugin) patch playing 8 simultaneous notes with 7 unison saw oscillators each, each note running through it's own 4x oversampled filter only consumes ~25% of one core's CPU on my AMD FX-8120.  A normal patch with few or no unison voices may consume less than 10% of one core.  This bodes well for the viability of future synthesizers that are more complex, or that use more computationally intensive BLIT or wavetable oscillators.  By comparison, none of my computers can adequately run a single instance of ZynSubAddFX.


Thanks,
Jeff



________________________________
 From: Jeffrey Hubbard <jhu...@ya...>
To: "DSS...@li..." <DSS...@li...> 
Sent: Monday, March 19, 2012 9:32 AM
Subject: Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"
 

Hi Jamie,

To be honest, I'd never heard of STK until now.  I have no practical experience with it, so I can't really say anything good or bad about their implementation, but I can detail mine:

1.  The audio DSP part of LibModSynth is written in C, instead of C++.  IMHO, C++ is not the best tool for the low level performance-critical bits(but then again, I'm not a big fan of C++ anyways, so I might just be biased).
2.  LibModSynth offers some exceptionally fast DSP math tailored specifically for audio.  The speed comes from plotting audio math that uses expensive functions like division, sin, cos, sinc, etc... into tables, and using cheap linear interpolation to approximate the results.  The tables were all carefully designed with just enough resolution to keep any artifacts from approximating the functions inaudible, but as small as possible to fit in CPU cache.  The included modules also use best practices in regards to not using division whenever possible, but rather calculating a reciprocal and multiplying instead.
3.  Eventually, I intend to create a visual plugin designer, where users can drag-n-drop components to build a plugin.  The killer feature of mine is that it will auto-generate a real C/C++ project folder from the visual design part.  The overall layout of the project files and UI design is all aimed at eventually being able to be auto-generated by a script, from an XML file.  This is also where all of my automatic compile/debug/packaging system is eventually heading.
4.  LibModSynth contains a selection of oscillators, filters, etc...  all designed for interoperability, performance and sound quality.
5.  The library parts are source based, instead of being a shared library.  This allows inlining of functions, as well as allowing developers to fork individual modules for each plugin.  This also provides greater performance from avoiding the overhead of calling functions from a shared library.

Thanks,
Jeff



________________________________
 From: Jamie Bullock <ja...@po...>
To: Jeffrey Hubbard <jhu...@ya...> 
Cc: "DSS...@li..." <DSS...@li...> 
Sent: Monday, March 19, 2012 6:50 AM
Subject: Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"
 

Hi Jeffrey,

This looks like an interesting project. Would you be able to say a little bit about the advantages of libmodsynth over writing DSSI wrappers around something like STK (https://ccrma.stanford.edu/software/stk/), or creating UI's for existing LADSPA plugins?

best,

Jamie


--
http://www.jamiebullock.com



On 17 Mar 2012, at 02:08, Jeffrey Hubbard wrote:

> Hello,
> 
> If you don't mind, I would like to have my DSSI plugins added to the list on your sourceforge page.  I currently have 5 plugins available they are:
> 
> Ray-V (analog-style lead synthesizer)
> LMS Filter (multimode filter)
> LMS Delay (delay with ping-pong and ducking)
> LMS Comb (Comb filter)
> LMS Distortion (hard-clipping distortion)
> 
> (or just collectively, the LibModSynth Plugin
 Suite)
> 
> ...I also have 3 more with an imminent release, at which point the suite will be 8 plugins strong.
> 
> 
> Here is my project page:
> 
> http://sourceforge.net/projects/libmodsynth/
> 
> Screenshots of the plugins:
> 
> http://libmodsynth.sourceforge.net/index.php?page=gallery
> 
> An example of what my early adopters are saying:
> 
> http://linuxmusicians.com/viewtopic.php?f=1&t=7834&sid=58f120b07bcf9bbf854649d0a5f72ee4
> 
> 
> The project itself, called LibModSynth, is a C audio-DSP library and set of developer tools for developing DSSI plugins with Qt GUIs.  However, I'm not yet promoting the developer parts too heavily just yet, because the API is still changing, and is not yet feature-complete.  
> 
> 
>
 Thanks,
> Jeff
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> DSSI-devel mailing list
> DSS...@li...
> https://lists.sourceforge.net/lists/listinfo/dssi-devel

Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"

[Jamie B. <ja...@po...>]

Hi Jeffrey,

FWIW, STK supports vector-based DSP, which can be give order-of-magnitude efficiency gain compared to sample-by-sample processing. STK does actually also use lookup-based oscillators.

However, that's beside the point, I was only using STK as one example of *one* existing library for audio processing. 

There are many others: SndObj, CSL, UGen++, Jamoma, CLAM, RTCmix, Maximilian, Gamma and pl-nk. I recently wrote a paper to be presented at the AES conference comparing these libraries using metrics for efficiency, memory use, expressiveness, documentation and ease-of-setup. 

There is also the wonderful FAUST project, which enables DSP to be specified using functional semantics, and then compiles to a number of targets including DSSI with a nice looking Qt UI. (http://faust.grame.fr/)

I'm not trying to rain on your parade, I just wonder if the real value of LibModSynth could be the killer feature you mentioned:

"I intend to create a visual plugin designer, where users can drag-n-drop components to build a plugin.  The killer feature of mine is that it will auto-generate a real C/C++ project folder from the visual design part. "

This sounds *amazing*. Why not implement the killer feature first, on top of an existing processing library, and write your own DSP code only if it proves necessary?

I'm not trying to criticise your work, I just think it would be a shame to spend a lot of time duplicating existing work and leave the killer feature until last. That UI sounds like a big project in itself.

best,

Jamie

--
http://www.jamiebullock.com



On 19 Mar 2012, at 18:06, Jeffrey Hubbard wrote:

> I was intrigued by STK, so I perused the source code to see if any the code could be translated to C and re-used in LibModSynth, and I think I can provide a better differentiation of LMS vs. STK now.
> 
> 
> part 2:
> 
> 1.  STK doesn't appear to be providing a complete implementation of all of it's modules, but more of just a starting point in many instances.  LibModSynth modules are more complete and ready-to-use in an actual plugin.
> 2.  STK doesn't have any of the more advanced performance optimizations that LMS has, for example:
> 
>       p_ = Stk::sampleRate() / frequency;    
> //It should be using the reciprocal of the sample rate and then multiplying, it would be about 10x faster
>       C2_ = 1 / p_;   
> //Once again, not the way to calculate something that could happen once per-tick of the sample rate clock.
>       rate_ = PI * C2_; 
>       this->updateHarmonics();
> 
> Also, the use of switch statements instead of function pointers seems to be prevalent, that's not going to make for very fast code unless the compiler can figure out a way to make it into a function pointer.
> STK also uses standard math libraries, the use of math.h/cmath/whatever functions won't be nearly as fast as LMS' math library functions using table lookups.
> 
> 
> 3.  LibModSynth allows for easy forking with a single command, and there is a work-in-progress script for generating a new empty plugin.  This gives developers a functional template to use as a starting point.
> 
> 4.  Memory management:  LMS avoids reinstantiaing the same variables over and over again, like iterators.  All variables of known size are declared in the type they'll be used with.
> 
> STK example code:
> 
>       for (i=99; i>=0; i--) {
>         fmGains_[i] = temp;
>         temp *= 0.933033;
>       }
> 
> 
> LMS example code:
> 
>     typedef struct st_some_oscillator{
>     //stuff
>     int iterator;
>     }
> 
>     osc->iterator = 0;
> 
>     while((osc->iterator) < 100){
>     //do something with osc
>     osc->iterator = (osc->iterator) + 1;
> 
> This avoids allocating and freeing new stack memory constantly, and keeps everything allocated a single time on the heap for the lifetime of the plugin.  Of course, the compiler might figure out some of these optimizations for you, but I don't leave it to chance.
> 
> 
> 
> Overall though, I think my optimized DSP strategy has already proven it's worth, a Ray-V(my plugin) patch playing 8 simultaneous notes with 7 unison saw oscillators each, each note running through it's own 4x oversampled filter only consumes ~25% of one core's CPU on my AMD FX-8120.  A normal patch with few or no unison voices may consume less than 10% of one core.  This bodes well for the viability of future synthesizers that are more complex, or that use more computationally intensive BLIT or wavetable oscillators.  By comparison, none of my computers can adequately run a single instance of ZynSubAddFX.
> 
> 
> Thanks,
> Jeff
> 
> 
> 
> ________________________________
> From: Jeffrey Hubbard <jhu...@ya...>
> To: "DSS...@li..." <DSS...@li...> 
> Sent: Monday, March 19, 2012 9:32 AM
> Subject: Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"
> 
> 
> Hi Jamie,
> 
> To be honest, I'd never heard of STK until now.  I have no practical experience with it, so I can't really say anything good or bad about their implementation, but I can detail mine:
> 
> 1.  The audio DSP part of LibModSynth is written in C, instead of C++.  IMHO, C++ is not the best tool for the low level performance-critical bits(but then again, I'm not a big fan of C++ anyways, so I might just be biased).
> 2.  LibModSynth offers some exceptionally fast DSP math tailored specifically for audio.  The speed comes from plotting audio math that uses expensive functions like division, sin, cos, sinc, etc... into tables, and using cheap linear interpolation to approximate the results.  The tables were all carefully designed with just enough resolution to keep any artifacts from approximating the functions inaudible, but as small as possible to fit in CPU cache.  The included modules also use best practices in regards to not using division whenever possible, but rather calculating a reciprocal and multiplying instead.
> 3.  Eventually, I intend to create a visual plugin designer, where users can drag-n-drop components to build a plugin.  The killer feature of mine is that it will auto-generate a real C/C++ project folder from the visual design part.  The overall layout of the project files and UI design is all aimed at eventually being able to be auto-generated by a script, from an XML file.  This is also where all of my automatic compile/debug/packaging system is eventually heading.
> 4.  LibModSynth contains a selection of oscillators, filters, etc...  all designed for interoperability, performance and sound quality.
> 5.  The library parts are source based, instead of being a shared library.  This allows inlining of functions, as well as allowing developers to fork individual modules for each plugin.  This also provides greater performance from avoiding the overhead of calling functions from a shared library.
> 
> Thanks,
> Jeff
> 
> 
> 
> ________________________________
> From: Jamie Bullock <ja...@po...>
> To: Jeffrey Hubbard <jhu...@ya...> 
> Cc: "DSS...@li..." <DSS...@li...> 
> Sent: Monday, March 19, 2012 6:50 AM
> Subject: Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"
> 
> 
> Hi Jeffrey,
> 
> This looks like an interesting project. Would you be able to say a little bit about the advantages of libmodsynth over writing DSSI wrappers around something like STK (https://ccrma.stanford.edu/software/stk/), or creating UI's for existing LADSPA plugins?
> 
> best,
> 
> Jamie
> 
> 
> --
> http://www.jamiebullock.com
> 
> 
> 
> On 17 Mar 2012, at 02:08, Jeffrey Hubbard wrote:
> 
>> Hello,
>> 
>> If you don't mind, I would like to have my DSSI plugins added to the list on your sourceforge page.  I currently have 5 plugins available they are:
>> 
>> Ray-V (analog-style lead synthesizer)
>> LMS Filter (multimode filter)
>> LMS Delay (delay with ping-pong and ducking)
>> LMS Comb (Comb filter)
>> LMS Distortion (hard-clipping distortion)
>> 
>> (or just collectively, the LibModSynth Plugin
> Suite)
>> 
>> ...I also have 3 more with an imminent release, at which point the suite will be 8 plugins strong.
>> 
>> 
>> Here is my project page:
>> 
>> http://sourceforge.net/projects/libmodsynth/
>> 
>> Screenshots of the plugins:
>> 
>> http://libmodsynth.sourceforge.net/index.php?page=gallery
>> 
>> An example of what my early adopters are saying:
>> 
>> http://linuxmusicians.com/viewtopic.php?f=1&t=7834&sid=58f120b07bcf9bbf854649d0a5f72ee4
>> 
>> 
>> The project itself, called LibModSynth, is a C audio-DSP library and set of developer tools for developing DSSI plugins with Qt GUIs.  However, I'm not yet promoting the developer parts too heavily just yet, because the API is still changing, and is not yet feature-complete.  
>> 
>> 
>> 
> Thanks,
>> Jeff
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here 
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> DSSI-devel mailing list
>> DSS...@li...
>> https://lists.sourceforge.net/lists/listinfo/dssi-devel
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> DSSI-devel mailing list
> DSS...@li...
> https://lists.sourceforge.net/lists/listinfo/dssi-devel

Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"

[Jeffrey H. <jhu...@ya...>]

Thanks for the feedback, but I think I'm going to stay the course with my original plan.  I'll give you a little background on myself, and why I'm doing this...

Back in the 2002 to 2009 era, I was a "roll-your-own-instruments" musician of roughly zero fame or reknown, on Windows using Cubase and later Reaper.  

During that time, I wrote one of everything, for my own personal use, and developed quite a bit of expertise in DSP.  I have a huge body of work that I use as a reference.


Around 2008, I discovered Linux, and eventually turned into a hardcore Linux evangelist.  I'm even a professional Linux Systems Administrator now.

Until recently, I had used Linux for everything but music creation.  My recent disdain with the direction that REAPER and the Windows driver stack are going
finally pushed me to go all-Linux.  Linux has decent DAWs like Qtractor, Rosegarden, etc...  but the choice of instruments and effects is still woefully lacking
compared to Windows.  Also, not to disrespect anybody's hard work, but quality of many(but not all) Linux plugins is below that of the average Windows plugin.

So, I decided, rather than attempting to be a one-man-army of plugin development, that I would develop a Linux equivalent of Windows tools such as Synthedit,
Synthmaker, Reaktor, etc...  that would allow musicians to easily write their own plugins, even without knowledge of how to write code.  The project was 

conceived with the notion of purpose-building such a tool from the ground up, and every line of code I've written has been with that final goal in mind.

As far as your concerns about me reinventing the wheel, I strongly disagree that it's a waste of time.  I've accomplished the following since registering the sourceforge project on 

January 10th, 2012:

* Wrote a library and plugin framework from the ground up that is stable, fast, and covers all of the audio DSP basics.
* Developed a GUI template and procedure that is easy to follow and automatable
*Developed a complete build/debug/packaging system that can do anything you would ever need it to with a single command
* Released 5 plugins that have been well received by the Linux music community


Not too bad for 2 months work by a single developer, developing it in his spare time, wouldn't you say?  I'm developing my own DSP because I already know how, and I trust my
own work more than the work of others.  If it took me 2 months to write all of the basics, then it shouldn't take more than 2-4 more months to finish most or all of the advanced parts.

Although, I am considering bringing other GPL-compatible code into my project, but I'm still evaluating actual code, and I may just stay the course with my own works.

At this point, the only thing holding me back from the visual designer is the fact that I had no Linux GUI experience coming into this project.  My only experience with GUIs
was Windows Forms (winforms) in C#/.NET 2.0, and echoing out basic HTML from PHP.  If winforms was an option on Linux, I'm sure I could write that designer in a month's time,
but as it stands I'm still fumbling my way through Qt, and considering the possibility of using GTK instead.

Of course, if somebody knowledgeable of Qt wanted to contribute a GUI designer application, I'm not too proud to ask for help with my project.  I was envisioning a Qt GUI that generates and
renders an SVG file for the graphical bits, and calls the Perl scripts I've already written to generate, compile, run and package a DSSI plugin.  It really would be pretty easy to write if
only I had any experience with Qt or SVG.

Anybody who wants to apply for the job can email me directly ;)



________________________________
 From: Jamie Bullock <ja...@po...>
To: Jeffrey Hubbard <jhu...@ya...> 
Cc: "DSS...@li..." <DSS...@li...> 
Sent: Tuesday, March 20, 2012 7:50 AM
Subject: Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"
 

Hi Jeffrey,

FWIW, STK supports vector-based DSP, which can be give order-of-magnitude efficiency gain compared to sample-by-sample processing. STK does actually also use lookup-based oscillators.

However, that's beside the point, I was only using STK as one example of *one* existing library for audio processing. 

There are many others: SndObj, CSL, UGen++, Jamoma, CLAM, RTCmix, Maximilian, Gamma and pl-nk. I recently wrote a paper to be presented at the AES conference comparing these libraries using metrics for efficiency, memory use, expressiveness, documentation and ease-of-setup. 

There is also the wonderful FAUST project, which enables DSP to be specified using functional semantics, and then compiles to a number of targets including DSSI with a nice looking Qt UI. (http://faust.grame.fr/)

I'm not trying to rain on your parade, I just wonder if the real value of LibModSynth could be the killer feature you mentioned:

"I intend to create a visual plugin designer, where users can drag-n-drop components to build a plugin.  The killer feature of mine is that it will auto-generate a real C/C++ project folder from the visual design part. "

This sounds *amazing*. Why not implement the killer feature first, on top of an existing processing library, and write your own DSP code only if it proves necessary?

I'm not trying to criticise your work, I just think it would be a shame to spend a lot of time duplicating existing work and leave the killer feature until last. That UI sounds like a big project in itself.

best,

Jamie

--
http://www.jamiebullock.com



On 19 Mar 2012, at 18:06, Jeffrey Hubbard wrote:

> I was intrigued by STK, so I perused the source code to see if any the code could be translated to C and re-used in LibModSynth, and I think I can provide a better differentiation of LMS vs. STK now.
> 
> 
> part 2:
> 
> 1.  STK doesn't appear to be providing a complete implementation of all of it's modules, but more of just a starting point in many instances.  LibModSynth modules are more complete and ready-to-use in an actual plugin.
> 2.  STK doesn't have any of the more advanced performance optimizations that LMS has, for example:
> 
>       p_ = Stk::sampleRate() / frequency;    
> //It should be using the reciprocal of the sample rate and then multiplying, it would be about 10x faster
>       C2_ = 1 / p_;  
> //Once again, not the way to calculate something that could happen once per-tick of the sample rate clock.
>       rate_ = PI * C2_; 
>       this->updateHarmonics();
> 
> Also, the use of switch statements instead of function pointers seems to be prevalent, that's not going to make for very fast code unless the compiler can figure out a way to make it into a function pointer.
> STK also uses standard math libraries, the use of math.h/cmath/whatever functions won't be nearly as fast as LMS' math library functions using table lookups.
> 
> 
> 3.  LibModSynth allows for easy forking with a single command, and there is a work-in-progress script for generating a new empty plugin.  This gives developers a functional template to use as a starting point.
> 
> 4.  Memory management:  LMS avoids reinstantiaing the same variables over and over again, like iterators.  All variables of known size are declared in the type they'll be used with.
> 
> STK example code:
> 
>       for (i=99; i>=0; i--) {
>         fmGains_[i] = temp;
>         temp *= 0.933033;
>       }
> 
> 
> LMS example code:
> 
>     typedef struct st_some_oscillator{
>     //stuff
>     int iterator;
>     }
> 
>     osc->iterator = 0;
> 
>     while((osc->iterator) < 100){
>     //do something with osc
>     osc->iterator = (osc->iterator) + 1;
> 
> This avoids allocating and freeing new stack memory constantly, and keeps everything allocated a single time on the heap for the lifetime of the plugin.  Of course, the compiler might figure out some of these optimizations for you, but I don't leave it to chance.
> 
> 
> 
> Overall though, I think my optimized DSP strategy has already proven it's worth, a Ray-V(my plugin) patch playing 8 simultaneous notes with 7 unison saw oscillators each, each note running through it's own 4x oversampled filter only consumes ~25% of one core's CPU on my AMD FX-8120.  A normal patch with few or no unison voices may consume less than 10% of one core.  This bodes well for the viability of future synthesizers that are more complex, or that use more computationally intensive BLIT or wavetable oscillators.  By comparison, none of my computers can adequately run a single instance of ZynSubAddFX.
> 
> 
> Thanks,
> Jeff
> 
> 
> 
> ________________________________
> From: Jeffrey Hubbard <jhu...@ya...>
> To: "DSS...@li..." <DSS...@li...> 
> Sent: Monday, March 19, 2012 9:32 AM
> Subject: Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"
> 
> 
> Hi Jamie,
> 
> To be honest, I'd never heard of STK until now.  I have no practical experience with it, so I can't really say anything good or bad about their implementation, but I can detail mine:
> 
> 1.  The audio DSP part of LibModSynth is written in C, instead of C++.  IMHO, C++ is not the best tool for the low level performance-critical bits(but then again, I'm not a big fan of C++ anyways, so I might just be biased).
> 2.  LibModSynth offers some exceptionally fast DSP math tailored specifically for audio.  The speed comes from plotting audio math that uses expensive functions like division, sin, cos, sinc, etc... into tables, and using cheap linear interpolation to approximate the results.  The tables were all carefully designed with just enough resolution to keep any artifacts from approximating the functions inaudible, but as small as possible to fit in CPU cache.  The included modules also use best practices in regards to not using division whenever possible, but rather calculating a reciprocal and multiplying instead.
> 3.  Eventually, I intend to create a visual plugin designer, where users can drag-n-drop components to build a plugin.  The killer feature of mine is that it will auto-generate a real C/C++ project folder from the visual design part.  The overall layout of the project files and UI design is all aimed at eventually being able to be auto-generated by a script, from an XML file.  This is also where all of my automatic compile/debug/packaging system is eventually heading.
> 4.  LibModSynth contains a selection of oscillators, filters, etc...  all designed for interoperability, performance and sound quality.
> 5.  The library parts are source based, instead of being a shared library.  This allows inlining of functions, as well as allowing developers to fork individual modules for each plugin.  This also provides greater performance from avoiding the overhead of calling functions from a shared library.
> 
> Thanks,
> Jeff
> 
> 
> 
> ________________________________
> From: Jamie Bullock <ja...@po...>
> To: Jeffrey Hubbard <jhu...@ya...> 
> Cc: "DSS...@li..." <DSS...@li...> 
> Sent: Monday, March 19, 2012 6:50 AM
> Subject: Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"
> 
> 
> Hi Jeffrey,
> 
> This looks like an interesting project. Would you be able to say a little bit about the advantages of libmodsynth over writing DSSI wrappers around something like STK (https://ccrma.stanford.edu/software/stk/), or creating UI's for existing LADSPA plugins?
> 
> best,
> 
> Jamie
> 
> 
> --
> http://www.jamiebullock.com
> 
> 
> 
> On 17 Mar 2012, at 02:08, Jeffrey Hubbard wrote:
> 
>> Hello,
>> 
>> If you don't mind, I would like to have my DSSI plugins added to the list on your sourceforge page.  I currently have 5 plugins available they are:
>> 
>> Ray-V (analog-style lead synthesizer)
>> LMS Filter (multimode filter)
>> LMS Delay (delay with ping-pong and ducking)
>> LMS Comb (Comb filter)
>> LMS Distortion (hard-clipping distortion)
>> 
>> (or just collectively, the LibModSynth Plugin
> Suite)
>> 
>> ...I also have 3 more with an imminent release, at which point the suite will be 8 plugins strong.
>> 
>> 
>> Here is my project page:
>> 
>> http://sourceforge.net/projects/libmodsynth/
>> 
>> Screenshots of the plugins:
>> 
>> http://libmodsynth.sourceforge.net/index.php?page=gallery
>> 
>> An example of what my early adopters are saying:
>> 
>> http://linuxmusicians.com/viewtopic.php?f=1&t=7834&sid=58f120b07bcf9bbf854649d0a5f72ee4
>> 
>> 
>> The project itself, called LibModSynth, is a C audio-DSP library and set of developer tools for developing DSSI plugins with Qt GUIs.  However, I'm not yet promoting the developer parts too heavily just yet, because the API is still changing, and is not yet feature-complete.  
>> 
>> 
>> 
> Thanks,
>> Jeff
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here 
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> DSSI-devel mailing list
>> DSS...@li...
>> https://lists.sourceforge.net/lists/listinfo/dssi-devel
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> DSSI-devel mailing list
> DSS...@li...
> https://lists.sourceforge.net/lists/listinfo/dssi-devel

Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"

[Sean B. <smb...@jp...>]

Hi Jeff,

I've added a link to LibModSynth to the DSSI website
list of plugins, plus added a section for DSSI development tools, which
includes LibModSynth, Faust (which should have had a mention long ago),
and FLAM.

Have you seen FLAM [1]? It builds custom Qt DSSI GUIs for LADSPA plugins
(and could trivially be extended to produce GUIs for DSSI plugins.)
There may be some interesting ideas for you there.

I also had a bit of time to play around with LibModSynth.  Here are
some comments, offered as constructive criticism with the knowledge
that what I've played with is an alpha snapshot, and you've probably
got most of these things on your to-do list already:

- On every softsynth I play with, I always end up wanting more knobs,
  and Ray-V is no exception.  Do you plan to add an LFO? I'd also like
  the velocity sensitivity to be adjustable (for both envelopes and the
  output amplitude.)

- I had to apply the attached patch to get Ray-V to build (and
  similarly for the other plugins). I don't know if this is one of those
  Debian library weirdnesses, or something unusual about your particular
  system, but you shouldn't need the 'qt4/' in your #includes.

- My preference is that a build system *never* require root
  privileges (nor should it need fakeroot, ideally). If it wants to
  suggest that I install dependencies, or suggest that I add my users to
  an 'audio' group, great, but I don't want the script to attempt to do
  it for me.

- Because of this, I need to be able to easily specify a temporary
  install path (e.g. 'make DESTDIR=/tmp/pkg install' or './waf install
  --destdir=/tmp/pkg') which I can then point my package-builder to.
  build.pl could pass DESTDIR to 'make install' pretty easily (though
  again, without the 'sudo').

- 'perl build.pl --fork' changes the plugin name, but not the plugin
  label? Plugin labels should be unique.

All in all, an interesting project.  I'm excited to see where you go
with it, especially (like Jamie said), the "killer feature" visual
plugin designer.

Thanks,

-Sean

[1] http://vagar.org/code/embedded/flam/index.html

diff -ur libmodsynth-git20120316/ray_v/src/synth_qt_gui.cpp libmodsynth-patched/ray_v/src/synth_qt_gui.cpp
--- libmodsynth-git20120316/ray_v/src/synth_qt_gui.cpp	2012-03-16 21:42:05.000000000 -0700
+++ libmodsynth-patched/ray_v/src/synth_qt_gui.cpp	2012-03-24 09:34:07.099218012 -0700
@@ -23,14 +23,14 @@
 #include <iostream>
 #include <unistd.h>
 
-#include <qt4/QtGui/qgroupbox.h>
-#include <qt4/QtGui/qlayout.h>
-#include <qt4/QtGui/qlabel.h>
-#include <qt4/QtGui/qgridlayout.h>
+#include <QtGui/qgroupbox.h>
+#include <QtGui/qlayout.h>
+#include <QtGui/qlabel.h>
+#include <QtGui/qgridlayout.h>
 #include <QFormLayout>
-#include <qt4/QtGui/qboxlayout.h>
+#include <QtGui/qboxlayout.h>
 #include <QGroupBox>
-#include <qt4/QtGui/qdial.h>
+#include <QtGui/qdial.h>
 #include <QPixmap>
 #include <QFile>
 #include <QDir>
diff -ur libmodsynth-git20120316/ray_v/src/synth_qt_gui.h libmodsynth-patched/ray_v/src/synth_qt_gui.h
--- libmodsynth-git20120316/ray_v/src/synth_qt_gui.h	2012-03-16 21:42:05.000000000 -0700
+++ libmodsynth-patched/ray_v/src/synth_qt_gui.h	2012-03-24 09:34:05.674236191 -0700
@@ -25,7 +25,7 @@
 #include <QGroupBox>
 #include <QComboBox>
 #include <QPushButton>
-#include <qt4/QtXml/QDomDocument>
+#include <QtXml/QDomDocument>
 #include <QPixmap>
 #include <QFile>
 #include <QDir>

Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"

[Jeffrey H. <jhu...@ya...>]

Hi Sean,

I haven't seen or heard FLAM, but I'll check it out.

1.  The LFO:  As a matter of fact, that was on my TODO list for the 12.04 release :)

2.  Velocity Sensitivity and more knobs:  Ray-V is meant to be as simple as possible while still being useful, as it's meant to be
a simple starting point that others can fork into their own plugin.   The only 2 features  I plan on adding are an LFO, and
my wavetable oscillator whenever it's finished.  


The next planned synth in the series, tentatively named "Way-V"(Wave), is going to have a large selection of wavetable oscillators,

 assignable envelopes, LFOs, FM synthesis, automation macro knobs and a full modulation matrix.  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 ;)


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.  Do you know how I can make jack-dssi-host pick up .so
files from an arbitrary location without modifying the source code to jack-dssi-host?  As far as the dependencies, I agree with you, that's just one of those
things that has been properly sorted out yet, but I will fix it.

4.  If that will make it more useful for you, then I'll gladly add it.  Honestly, I'm still a complete noob to Linux development, 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.


5.  Oops...   I didn't know what that was for....  I'll fix that today.

I really do appreciate the feedback.  I should be able to have all of the fixes and modifications you suggested implemented by next weekend or so.

Thanks,
Jeff

Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"

[Sean B. <smb...@jp...>]

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

Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"

[Jeffrey H. <jhu...@ya...>]

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

Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"

[Jeffrey H. <jhu...@ya...>]

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

Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"

[Sean B. <smb...@jp...>]

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

Re: [DSSI] Request to have my project added to your list of "Currently available plugins include:"

[Jeffrey H. <jhu...@ya...>]

Makes sense.  Thanks Sean. 

[DSSI] Question about Trivial_Sampler

[Jeffrey H. <jhu...@ya...>]

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

Re: [DSSI] Question about Trivial_Sampler

[Jeffrey H. <jhu...@ya...>]

>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.

Re: [DSSI] Question about Trivial_Sampler

[Jeffrey H. <jhu...@ya...>]

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.

Re: [DSSI] Question about Trivial_Sampler

[Jeffrey H. <jhu...@ya...>]

>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