From: Tim E. R. <ter...@ro...> - 2012-11-25 08:51:56
|
http://dl.dropbox.com/u/53315356/native_vst_first_run.png http://www.mucoder.net/en/tonespace/ Tim. |
From: Dan M. <al...@gm...> - 2012-11-25 09:24:04
|
Heavens to Mergatroyd! :O Does at least that plugin really, actually fully work yet? How many plugins have you tried and how close are you to having something for Dan R. Public to test? Great work Tim! :D On Sun, Nov 25, 2012 at 8:51 AM, Tim E. Real <ter...@ro...> wrote: > > http://dl.dropbox.com/u/53315356/native_vst_first_run.png > > http://www.mucoder.net/en/tonespace/ > > Tim. > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Lmuse-user mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-user > |
From: Tim E. R. <ter...@ro...> - 2012-12-07 08:02:20
|
Feature: Native VST instruments support. Now in the SVN trunk. Here's what I got so far. Try er' out. Remember things may change slightly (or wholly?) so let's give a thorough workout to weed out any bugs. Best results are from compiling with the vst sdk. Featuring: True sample-accurate parameter automation! Full native GUI support for TOUCH, WRITE modes! New cmake options for: Enabling native vst. Enabling true sdk support . The vst header path. Plugins environment variable is currently VST_NATIVE_PATH else "/usr/lib/vst:/usr/local/lib/vst". What should we do there for paths and env var, eh folks? TODOs: Parameter ranges: fixed at linear 0.0 - 1.0 for now. Program categories. Dynamic port changes. Plugins correct path and env var? No rack effect plugins yet. And so on... --------------------------------- NOTICE: Plugins vary widely in quality. Some may crash MusE upon startup, while using MusE, or particularly most common - upon closing MusE. Be careful what you put in the plugin directory! Advice is to try one-at-a-time, or use the -D switch to see what plugin might be crashing MusE at startup. --------------------------------- Lemme know if any of them cause trouble. I'll take them out back and have a stern talk with them... Tim. |
From: Dan M. <al...@gm...> - 2012-12-07 18:27:00
|
Back again! You'll be seeing more more of me on here now I expect so get used to it! :) On Fri, Dec 7, 2012 at 8:02 AM, Tim E. Real <ter...@ro...> wrote: > > Best results are from compiling with the vst sdk. > So you say but which version have you been using to test against Tim? I would expect Steinberg VST 2.4 is best and that 3.x will be unsupported as is the case for the other Linux DAWs right? > > What should we do there for paths and env var, eh folks? > > TODOs: Parameter ranges: fixed at linear 0.0 - 1.0 for now. > Program categories. Dynamic port changes. > Plugins correct path and env var? > No rack effect plugins yet. > > I think both qtractor and A3 use VST_PATH for the env var Come back quick Tim! :D |
From: Dan M. <al...@gm...> - 2012-12-07 20:07:20
|
Its true!!! Tim you generous genius you and just in time for xmas too! Thanks so much for sorting this out! :) Muse svn complies fine if you just stick to using compile_muse.sh ie Vestige headers and although I've only done the most bare minimum of testing so far, Aspect seems to work so thats a huge win right there but so far I'm not having any luck getting any usable sound out of TAL-Noisemaker yet unfortunately - this is under Deb Wheezy amd64. I'll try Deb squeeze x86 soon. Another prob I have with Noisemaker is I was unable to see where I might be able to select one of its integrated presets or is this not supported yet Tim? My biggest problem right now with the newly born plugin support is I don't see any other way of opening any of the VST plugins windows other than clicking the GUI column for the plugin under the MIDI ports / soft synths window which seems a bit awkward to me. There are 3/4 ways I'd expect/like to be able to open the VST etc. plugins GUI window: 1 - When a VST plugin 'track'/object is selected in the arranger you should be able to either double-click on the plugin name/ title at the top of the plugins column on the left or right click and select 'Edit'. 2 - Double-clicking on any of the synth / VST plugin icons in the arrangers 'Track Type' column 3 - As 1 but in the Mixer window columns too If you can get at least one of those in Tim I'll be even happier! Well done Tim! You've made my Christmas! :D On Fri, Dec 7, 2012 at 8:02 AM, Tim E. Real <ter...@ro...> wrote: > Feature: Native VST instruments support. > Now in the SVN trunk. > > Here's what I got so far. Try er' out. Remember things may > change slightly (or wholly?) so let's give a thorough workout > to weed out any bugs. > > Best results are from compiling with the vst sdk. > > Featuring: > True sample-accurate parameter automation! > Full native GUI support for TOUCH, WRITE modes! > > New cmake options for: > Enabling native vst. > Enabling true sdk support . > The vst header path. > > Plugins environment variable is currently VST_NATIVE_PATH > else "/usr/lib/vst:/usr/local/lib/vst". > > What should we do there for paths and env var, eh folks? > > TODOs: Parameter ranges: fixed at linear 0.0 - 1.0 for now. > Program categories. Dynamic port changes. > Plugins correct path and env var? > No rack effect plugins yet. > > And so on... > > --------------------------------- > NOTICE: Plugins vary widely in quality. Some may crash MusE upon startup, > while using MusE, or particularly most common - > upon closing MusE. > Be careful what you put in the plugin directory! > Advice is to try one-at-a-time, or use the -D > switch to see what plugin > might be crashing MusE at startup. > --------------------------------- > > Lemme know if any of them cause trouble. > I'll take them out back and have a stern talk with them... > > Tim. > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Lmuse-user mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-user > |
From: Dan M. <al...@gm...> - 2012-12-08 08:57:07
|
Hi Tim! I've done a clean checkout and it seems you've removed vestige support for the moment so running the compile script now generates a native VST-less build. I hope we can see both Vestige and VST support in the next rc. I'd prefer to use the SDK but it still isn't building here. I should note that I have used these exact same headers to compile qtractor and the DISTRHO VST plugs so its not a prob with my headers. Deb Wheezy amd64 w/ VST 2.4: [ 51%] Building CXX object muse/widgets/CMakeFiles/widgets.dir/vst_native_editor.o In file included from /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffectx.h:17:0, from /home/dan/src/lmuse/muse2/muse/vst_native.h:45, from /home/dan/src/lmuse/muse2/muse/widgets/vst_native_editor.cpp:25: /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:125:32: error: expected ‘)’ before ‘*’ token In file included from /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffectx.h:17:0, from /home/dan/src/lmuse/muse2/muse/vst_native.h:45, from /home/dan/src/lmuse/muse2/muse/widgets/vst_native_editor.cpp:25: /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:126:32: error: expected ‘)’ before ‘*’ token /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:127:27: error: expected ‘)’ before ‘*’ token /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:128:27: error: expected ‘)’ before ‘*’ token /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:129:27: error: expected ‘)’ before ‘*’ token /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:130:28: error: expected ‘)’ before ‘*’ token /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:149:2: error: ‘AEffectDispatcherProc’ does not name a type /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:152:2: error: ‘AEffectProcessProc’ does not name a type /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:155:2: error: ‘AEffectSetParameterProc’ does not name a type /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:158:2: error: ‘AEffectGetParameterProc’ does not name a type /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:183:2: error: ‘AEffectProcessProc’ does not name a type /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:187:2: error: ‘AEffectProcessDoubleProc’ does not name a type In file included from /home/dan/src/lmuse/muse2/muse/widgets/vst_native_editor.cpp:25:0: /home/dan/src/lmuse/muse2/muse/vst_native.h: In member function ‘VstIntPtr MusECore::VstNativeSynthIF::dispatch(VstInt32, VstInt32, VstIntPtr, void*, float) const’: /home/dan/src/lmuse/muse2/muse/vst_native.h:187:47: error: ‘struct AEffect’ has no member named ‘dispatcher’ make[2]: *** [muse/widgets/CMakeFiles/widgets.dir/vst_native_editor.o] Error 1 make[1]: *** [muse/widgets/CMakeFiles/widgets.dir/all] Error 2 make: *** [all] Error 2 On Sat, Dec 8, 2012 at 8:37 AM, Tim E. Real <ter...@ro...> wrote: > On December 7, 2012 08:07:12 PM Dan MacDonald wrote: > > > Its true!!! > > > > Tim you generous genius you and just in time for xmas too! Thanks so much > > for sorting this out! :) > > > > Muse svn complies fine if you just stick to using compile_muse.sh ie > Vestige > > headers and although I've only done the most bare minimum of testing so > far, > > Aspect seems to work so thats a huge win right there but so far I'm not > > having any luck getting any usable sound out of TAL-Noisemaker yet > > unfortunately - this is under Deb Wheezy amd64. I'll try Deb squeeze x86 > > soon. > > > > > > -------------- > Try it now. > > - Native VST fixes and changes. > > Redid cmake options. Please do 'prune' and carefully reconfigure. > > (Dan can you please try the sdk again? Would help. > Currently the only real benefit is Chunks, otherwise most of the > native VSTs seem to mostly function fine with without it. > Maybe not surprising considering the target users?) > > Fixed track info banks and patch popup list bank issues. > > Fixed plugins such as NoizeMaker: Kill harmful redundancies - > call getParameter before setParameter. > > Fixed crash reloading song with huge-chunk plugin like NoizeMaker: > Stack overflow in processEvent(). > TODO: Fix all other such sysex stack buffer usages like possibly in DSSI. > > -------------------- > > > Another prob I have with Noisemaker is I was unable to see where I might > be > > able to select one of its integrated presets or is this not supported yet > > Tim? > > Create a midi track and select the synth as it's output device, then > operate > the trackinfo bankH, bankL, and program boxes, or simply choose the patch > from the instrument patch list popup button (above the boxes), which I > just fixed. > > Now, if you are referring to the /generic/ GUIs, the non-'native' ones, > yes I'm keenly aware that our generic GUI windows do not have a program > box. > This problem hit me straight on when I added DSSI synth plugins (opposite > of > effect plugins), as rack effects. No mechanism to set program! Such as > with > several of the Calf DSSI plugins. Also no mechanism to direct midi to the > effect plugin, which might use it. > > And so here this problem has come around again with the vst, been thinking > about it a lot lately because we will need to add vsts and lv2s as rack > plugins soon. It involves changes to our Plugin classes, been studying it. > > > > > My biggest problem right now with the newly born plugin support is I > don't > > see any other way of opening any of the VST plugins windows other than > > clicking the GUI column for the plugin under the MIDI ports / soft synths > > window which seems a bit awkward to me. > > Agreed. > > Bit of an oversight. Normally the other MESS synths open automatically > right away. But DSSI-VST support presented a problem: When you close > a DSSI-VST 'native' GUI window via the window's 'X', you cannot open it > again. Same behaviour as in Rosegarden. > However in MusE if you stick using to the popup 'show generic/native GUI' > menu, it works every time ! > > Em, thus I wanted to kinda force users to learn that poup menu, so I > kept 'em closed at creation. Well, that and the GUIs can be complicated > and take time and some may want to work strictly with the generic GUI > (which... again... has no program box... sigh). And so on. > > Here with Native VSTs, we needn't worry too much about all that, > so it's do-able. > > > > > There are 3/4 ways I'd expect/like to be able to open the VST etc. > plugins > > GUI window: > > > > 1 - When a VST plugin 'track'/object is selected in the arranger you > should > > be able to either double-click on the plugin name/ title at the top of > the > > plugins column on the left or right click and select 'Edit'. > > > > 2 - Double-clicking on any of the synth / VST plugin icons in the > arrangers > > 'Track Type' column > > > > 3 - As 1 but in the Mixer window columns too > > Agreed it should be better. Been studying those columns some more. > I have always kinda hated that left-click ports popup menu versus the > right-click 'show gui' menu. > > I think we should unify the two onto the right click menu. > Thus it would clear the way to use left-click or double-left-click as > 'show native gui', or the fall-back 'show gui'. > > Also would like to unify several other kinda sloppy menu arrangements. > > Tim. > > > > > If you can get at least one of those in Tim I'll be even happier! > > > > Well done Tim! You've made my Christmas! > > > > :D > > > > > > On Fri, Dec 7, 2012 at 8:02 AM, Tim E. Real <ter...@ro...> > wrote: > > > > > > Feature: Native VST instruments support. > > > Now in the SVN trunk. > > > > > > Here's what I got so far. Try er' out. Remember things may > > > change slightly (or wholly?) so let's give a thorough workout > > > to weed out any bugs. > > > > > > Best results are from compiling with the vst sdk. > > > > > > Featuring: > > > True sample-accurate parameter automation! > > > Full native GUI support for TOUCH, WRITE modes! > > > > > > New cmake options for: > > > Enabling native vst. > > > Enabling true sdk support . > > > The vst header path. > > > > > > Plugins environment variable is currently VST_NATIVE_PATH > > > else "/usr/lib/vst:/usr/local/lib/vst". > > > > > > What should we do there for paths and env var, eh folks? > > > > > > TODOs: Parameter ranges: fixed at linear 0.0 - 1.0 for now. > > > Program categories. Dynamic port changes. > > > Plugins correct path and env var? > > > No rack effect plugins yet. > > > > > > And so on... > > > > > > --------------------------------- > > > NOTICE: Plugins vary widely in quality. Some may crash MusE upon > startup, > > > while using MusE, or particularly most common > - > > > upon closing MusE. > > > Be careful what you put in the plugin > directory! > > > Advice is to try one-at-a-time, or use the -D > > > switch to see what plugin > > > might be crashing MusE at startup. > > > --------------------------------- > > > > > > Lemme know if any of them cause trouble. > > > I'll take them out back and have a stern talk with them... > > > > > > Tim. > > > > > |
From: Dan M. <al...@gm...> - 2012-12-09 08:11:05
|
The latest svn compiles fine with Vestige and the build script so I'm just about to test that build but before doing so I wanted to try building with the SDK again but again, no luck. I thought it best if I be a bit more verbose on how I'm trying to build with the SDK this time just in case I'm doing something wrong: U lmuse Checked out revision 1650. dan@dannv:~/src$ cd vstsdk2.4/pluginterfaces/vst2.x/ dan@dannv:~/src/vstsdk2.4/pluginterfaces/vst2.x$ ls -l total 88 -rw-r--r-- 1 dan dan 16961 Jun 20 2006 aeffect.h -rw-r--r-- 1 dan dan 64725 Jun 20 2006 aeffectx.h -rw-r--r-- 1 dan dan 4044 Feb 10 2006 vstfxstore.h dan@dannv:~/src/vstsdk2.4/pluginterfaces/vst2.x$ pwd /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x dan@dannv:~/src/vstsdk2.4/pluginterfaces/vst2.x$ cd ~/src/lmuse/muse2/ dan@dannv:~/src/lmuse/muse2$ mkdir build dan@dannv:~/src/lmuse/muse2$ cd build/ dan@dannv:~/src/lmuse/muse2/build$ cmake -i .. Would you like to see advanced options? [No]: Please wait while cmake processes CMakeLists.txt files.... Doxygen not found vst header path: /home/dan/src/lmuse/muse2/vestige Unix (probably linux) found Native VST support enabled ** ERROR: The program 'doxygen' is required, but was not found. ** WARNING: lash (>= 0.2) was enabled, but development files were not found. ** HINT: Don't have LASH? Try installing the LADISH LASH compatibility package instead. The following components will be built: ----------------------------------------------- OSC (Liblo) support DSSI support Native VST support Fluidsynth support The following components WILL NOT be built: ----------------------------------------------- Lash support Python support Experimental features Internal modules will be built as shared components. Build type: CMAKE_BUILD_TYPE is empty. Plain un-optimized build. Variable Name: CMAKE_BACKWARDS_COMPATIBILITY Description: For backwards compatibility, what version of CMake commands and syntax should this version of CMake try to support. Current Value: 2.4 New Value (Enter to keep current value): Variable Name: CMAKE_BUILD_TYPE Description: Choose the type of build, options are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel. Current Value: New Value (Enter to keep current value): Variable Name: CMAKE_INSTALL_PREFIX Description: Install path prefix, prepended onto install directories. Current Value: /usr/local New Value (Enter to keep current value): Variable Name: DOXY Description: Path to a program. Current Value: DOXY-NOTFOUND New Value (Enter to keep current value): Variable Name: ENABLE_DSSI Description: Enable Disposable Soft Synth Interface (dssi) (OSC also recommended) Current Value: ON New Value (Enter to keep current value): Variable Name: ENABLE_EXPERIMENTAL Description: Enable building experimental features. Current Value: OFF New Value (Enter to keep current value): Variable Name: ENABLE_FLUID Description: Enable fluidsynth softsynth plugins. Current Value: ON New Value (Enter to keep current value): Variable Name: ENABLE_LASH Description: Enable LASH Audio Session Handler (or LADISH compatibility layer) Current Value: ON New Value (Enter to keep current value): OFF Variable Name: ENABLE_OSC Description: Enable Lightweight Open Sound Control (liblo) (DSSI also recommended) Current Value: ON New Value (Enter to keep current value): Variable Name: ENABLE_PYTHON Description: Enable Python control support. Current Value: OFF New Value (Enter to keep current value): Variable Name: ENABLE_VST Description: Enable VST/win support (deprecated) Current Value: OFF New Value (Enter to keep current value): Variable Name: ENABLE_VST_NATIVE Description: Enable Native VST support (see ENABLE_VST_VESTIGE and VST_HEADER_PATH) Current Value: ON New Value (Enter to keep current value): Variable Name: ENABLE_VST_VESTIGE Description: Set VST header type is Vestige Current Value: ON New Value (Enter to keep current value): OFF Variable Name: EXECUTABLE_OUTPUT_PATH Description: Single output directory for building all executables. Current Value: New Value (Enter to keep current value): Variable Name: LIBRARY_OUTPUT_PATH Description: Single output directory for building all libraries. Current Value: New Value (Enter to keep current value): Variable Name: LIB_SUFFIX Description: Suffix for installed library path. Ex. 64 for lib64 Current Value: New Value (Enter to keep current value): Variable Name: MODULES_BUILD_STATIC Description: Build type of internal modules Current Value: OFF New Value (Enter to keep current value): Variable Name: QT_QMAKE_EXECUTABLE Description: The qmake executable for the Qt installation to use Current Value: /usr/bin/qmake New Value (Enter to keep current value): Variable Name: SVNVER Description: Path to a program. Current Value: /usr/bin/svnversion New Value (Enter to keep current value): Variable Name: UPDATE_TRANSLATIONS Description: Update source translation share/locale/*.ts files (WARNING: This will modify the .ts files in the source tree!!) Current Value: OFF New Value (Enter to keep current value): Variable Name: VST_HEADER_PATH Description: Path to vst header files (aeffectx.h). Default is ./vestige. See ENABLE_VST_VESTIGE. Current Value: /home/dan/src/lmuse/muse2/vestige New Value (Enter to keep current value): /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x Please wait while cmake processes CMakeLists.txt files.... Doxygen not found vst header path: /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x Unix (probably linux) found LASH disabled Native VST support enabled ** ERROR: The program 'doxygen' is required, but was not found. The following components will be built: ----------------------------------------------- OSC (Liblo) support DSSI support Native VST support Fluidsynth support The following components WILL NOT be built: ----------------------------------------------- Lash support Python support Experimental features Internal modules will be built as shared components. Build type: CMAKE_BUILD_TYPE is empty. Plain un-optimized build. CMake complete, run make to build project. dan@dannv:~/src/lmuse/muse2/build$ make ... [ 51%] Building CXX object muse/widgets/CMakeFiles/widgets.dir/vst_native_editor.o In file included from /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffectx.h:17:0, from /home/dan/src/lmuse/muse2/muse/vst_native.h:45, from /home/dan/src/lmuse/muse2/muse/widgets/vst_native_editor.cpp:25: /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:125:32: error: expected ‘)’ before ‘*’ token In file included from /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffectx.h:17:0, from /home/dan/src/lmuse/muse2/muse/vst_native.h:45, from /home/dan/src/lmuse/muse2/muse/widgets/vst_native_editor.cpp:25: /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:126:32: error: expected ‘)’ before ‘*’ token /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:127:27: error: expected ‘)’ before ‘*’ token /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:128:27: error: expected ‘)’ before ‘*’ token /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:129:27: error: expected ‘)’ before ‘*’ token /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:130:28: error: expected ‘)’ before ‘*’ token /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:149:2: error: ‘AEffectDispatcherProc’ does not name a type /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:152:2: error: ‘AEffectProcessProc’ does not name a type /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:155:2: error: ‘AEffectSetParameterProc’ does not name a type /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:158:2: error: ‘AEffectGetParameterProc’ does not name a type /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:183:2: error: ‘AEffectProcessProc’ does not name a type /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:187:2: error: ‘AEffectProcessDoubleProc’ does not name a type In file included from /home/dan/src/lmuse/muse2/muse/widgets/vst_native_editor.cpp:25:0: /home/dan/src/lmuse/muse2/muse/vst_native.h: In member function ‘VstIntPtr MusECore::VstNativeSynthIF::dispatch(VstInt32, VstInt32, VstIntPtr, void*, float) const’: /home/dan/src/lmuse/muse2/muse/vst_native.h:187:47: error: ‘struct AEffect’ has no member named ‘dispatcher’ make[2]: *** [muse/widgets/CMakeFiles/widgets.dir/vst_native_editor.o] Error 1 make[1]: *** [muse/widgets/CMakeFiles/widgets.dir/all] Error 2 make: *** [all] Error 2 |
From: Tim E. R. <ter...@ro...> - 2012-12-08 08:37:29
|
On December 7, 2012 08:07:12 PM Dan MacDonald wrote: > Its true!!! > > Tim you generous genius you and just in time for xmas too! Thanks so much > for sorting this out! :) > > Muse svn complies fine if you just stick to using compile_muse.sh ie Vestige > headers and although I've only done the most bare minimum of testing so far, > Aspect seems to work so thats a huge win right there but so far I'm not > having any luck getting any usable sound out of TAL-Noisemaker yet > unfortunately - this is under Deb Wheezy amd64. I'll try Deb squeeze x86 > soon. > > -------------- Try it now. - Native VST fixes and changes. Redid cmake options. Please do 'prune' and carefully reconfigure. (Dan can you please try the sdk again? Would help. Currently the only real benefit is Chunks, otherwise most of the native VSTs seem to mostly function fine with without it. Maybe not surprising considering the target users?) Fixed track info banks and patch popup list bank issues. Fixed plugins such as NoizeMaker: Kill harmful redundancies - call getParameter before setParameter. Fixed crash reloading song with huge-chunk plugin like NoizeMaker: Stack overflow in processEvent(). TODO: Fix all other such sysex stack buffer usages like possibly in DSSI. -------------------- > Another prob I have with Noisemaker is I was unable to see where I might be > able to select one of its integrated presets or is this not supported yet > Tim? Create a midi track and select the synth as it's output device, then operate the trackinfo bankH, bankL, and program boxes, or simply choose the patch from the instrument patch list popup button (above the boxes), which I just fixed. Now, if you are referring to the /generic/ GUIs, the non-'native' ones, yes I'm keenly aware that our generic GUI windows do not have a program box. This problem hit me straight on when I added DSSI synth plugins (opposite of effect plugins), as rack effects. No mechanism to set program! Such as with several of the Calf DSSI plugins. Also no mechanism to direct midi to the effect plugin, which might use it. And so here this problem has come around again with the vst, been thinking about it a lot lately because we will need to add vsts and lv2s as rack plugins soon. It involves changes to our Plugin classes, been studying it. > > My biggest problem right now with the newly born plugin support is I don't > see any other way of opening any of the VST plugins windows other than > clicking the GUI column for the plugin under the MIDI ports / soft synths > window which seems a bit awkward to me. Agreed. Bit of an oversight. Normally the other MESS synths open automatically right away. But DSSI-VST support presented a problem: When you close a DSSI-VST 'native' GUI window via the window's 'X', you cannot open it again. Same behaviour as in Rosegarden. However in MusE if you stick using to the popup 'show generic/native GUI' menu, it works every time ! Em, thus I wanted to kinda force users to learn that poup menu, so I kept 'em closed at creation. Well, that and the GUIs can be complicated and take time and some may want to work strictly with the generic GUI (which... again... has no program box... sigh). And so on. Here with Native VSTs, we needn't worry too much about all that, so it's do-able. > > There are 3/4 ways I'd expect/like to be able to open the VST etc. plugins > GUI window: > > 1 - When a VST plugin 'track'/object is selected in the arranger you should > be able to either double-click on the plugin name/ title at the top of the > plugins column on the left or right click and select 'Edit'. > > 2 - Double-clicking on any of the synth / VST plugin icons in the arrangers > 'Track Type' column > > 3 - As 1 but in the Mixer window columns too Agreed it should be better. Been studying those columns some more. I have always kinda hated that left-click ports popup menu versus the right-click 'show gui' menu. I think we should unify the two onto the right click menu. Thus it would clear the way to use left-click or double-left-click as 'show native gui', or the fall-back 'show gui'. Also would like to unify several other kinda sloppy menu arrangements. Tim. > > If you can get at least one of those in Tim I'll be even happier! > > Well done Tim! You've made my Christmas! > > :D > > > On Fri, Dec 7, 2012 at 8:02 AM, Tim E. Real <ter...@ro...> wrote: > > > > Feature: Native VST instruments support. > > Now in the SVN trunk. > > > > Here's what I got so far. Try er' out. Remember things may > > change slightly (or wholly?) so let's give a thorough workout > > to weed out any bugs. > > > > Best results are from compiling with the vst sdk. > > > > Featuring: > > True sample-accurate parameter automation! > > Full native GUI support for TOUCH, WRITE modes! > > > > New cmake options for: > > Enabling native vst. > > Enabling true sdk support . > > The vst header path. > > > > Plugins environment variable is currently VST_NATIVE_PATH > > else "/usr/lib/vst:/usr/local/lib/vst". > > > > What should we do there for paths and env var, eh folks? > > > > TODOs: Parameter ranges: fixed at linear 0.0 - 1.0 for now. > > Program categories. Dynamic port changes. > > Plugins correct path and env var? > > No rack effect plugins yet. > > > > And so on... > > > > --------------------------------- > > NOTICE: Plugins vary widely in quality. Some may crash MusE upon startup, > > while using MusE, or particularly most common - > > upon closing MusE. > > Be careful what you put in the plugin directory! > > Advice is to try one-at-a-time, or use the -D > > switch to see what plugin > > might be crashing MusE at startup. > > --------------------------------- > > > > Lemme know if any of them cause trouble. > > I'll take them out back and have a stern talk with them... > > > > Tim. > > |
From: Tim E. R. <ter...@ro...> - 2012-12-08 10:39:36
|
On December 8, 2012 08:56:59 AM Dan MacDonald wrote: Hi Tim! I've done a clean checkout and it seems you've removed vestige support for the moment -- For the moment just put a vestige header in the vestige directory. Don't worry it still works. I tested it here. Well actually I used the one from falkTx's DSSI-VST repo. It seemed more recent than other versions. so running the compile script now generates a native VST-less build. I hope we can see both Vestige and VST support in the next rc. I'd prefer to use the SDK but it still isn't building here. I should note that I have used these exact same headers to compile qtractor and the DISTRHO VST plugs so its not a prob with my headers. -- Hm. OK thanks, sorry 'bout the still broken sdk part, I will try some more. Try the vestige again. Tim. Deb Wheezy amd64 w/ VST 2.4: [ 51%] Building CXX object muse/widgets/CMakeFiles/widgets.dir/vst_native_editor.o In file included from /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffectx.h:17:0, from /home/dan/src/lmuse/muse2/muse/vst_native.h:45, from /home/dan/src/lmuse/muse2/muse/widgets/vst_native_editor.cpp:25: /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:125:32: error: expected ‘)’ before ‘*’ token In file included from /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffectx.h:17:0, from /home/dan/src/lmuse/muse2/muse/vst_native.h:45, from /home/dan/src/lmuse/muse2/muse/widgets/vst_native_editor.cpp:25: /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:126:32: error: expected ‘)’ before ‘*’ token /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:127:27: error: expected ‘)’ before ‘*’ token /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:128:27: error: expected ‘)’ before ‘*’ token /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:129:27: error: expected ‘)’ before ‘*’ token /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:130:28: error: expected ‘)’ before ‘*’ token /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:149:2: error: ‘AEffectDispatcherProc’ does not name a type /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:152:2: error: ‘AEffectProcessProc’ does not name a type /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:155:2: error: ‘AEffectSetParameterProc’ does not name a type /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:158:2: error: ‘AEffectGetParameterProc’ does not name a type /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:183:2: error: ‘AEffectProcessProc’ does not name a type /home/dan/src/vstsdk2.4/pluginterfaces/vst2.x/aeffect.h:187:2: error: ‘AEffectProcessDoubleProc’ does not name a type In file included from /home/dan/src/lmuse/muse2/muse/widgets/vst_native_editor.cpp:25:0: /home/dan/src/lmuse/muse2/muse/vst_native.h: In member function ‘VstIntPtr MusECore::VstNativeSynthIF::dispatch(VstInt32, VstInt32, VstIntPtr, void*, float) const’: /home/dan/src/lmuse/muse2/muse/vst_native.h:187:47: error: ‘struct AEffect’ has no member named ‘dispatcher’ make[2]: *** [muse/widgets/CMakeFiles/widgets.dir/vst_native_editor.o] Error 1 make[1]: *** [muse/widgets/CMakeFiles/widgets.dir/all] Error 2 make: *** [all] Error 2 On Sat, Dec 8, 2012 at 8:37 AM, Tim E. Real <ter...@ro...> wrote: On December 7, 2012 08:07:12 PM Dan MacDonald wrote: > Its true!!! > > Tim you generous genius you and just in time for xmas too! Thanks so much > for sorting this out! :) > > Muse svn complies fine if you just stick to using compile_muse.sh ie Vestige > headers and although I've only done the most bare minimum of testing so far, > Aspect seems to work so thats a huge win right there but so far I'm not > having any luck getting any usable sound out of TAL-Noisemaker yet > unfortunately - this is under Deb Wheezy amd64. I'll try Deb squeeze x86 > soon. > > -------------- Try it now. - Native VST fixes and changes. Redid cmake options. Please do 'prune' and carefully reconfigure. (Dan can you please try the sdk again? Would help. Currently the only real benefit is Chunks, otherwise most of the native VSTs seem to mostly function fine with without it. Maybe not surprising considering the target users?) Fixed track info banks and patch popup list bank issues. Fixed plugins such as NoizeMaker: Kill harmful redundancies - call getParameter before setParameter. Fixed crash reloading song with huge-chunk plugin like NoizeMaker: Stack overflow in processEvent(). TODO: Fix all other such sysex stack buffer usages like possibly in DSSI. -------------------- > Another prob I have with Noisemaker is I was unable to see where I might be > able to select one of its integrated presets or is this not supported yet > Tim? Create a midi track and select the synth as it's output device, then operate the trackinfo bankH, bankL, and program boxes, or simply choose the patch from the instrument patch list popup button (above the boxes), which I just fixed. Now, if you are referring to the /generic/ GUIs, the non-'native' ones, yes I'm keenly aware that our generic GUI windows do not have a program box. This problem hit me straight on when I added DSSI synth plugins (opposite of effect plugins), as rack effects. No mechanism to set program! Such as with several of the Calf DSSI plugins. Also no mechanism to direct midi to the effect plugin, which might use it. And so here this problem has come around again with the vst, been thinking about it a lot lately because we will need to add vsts and lv2s as rack plugins soon. It involves changes to our Plugin classes, been studying it. > > My biggest problem right now with the newly born plugin support is I don't > see any other way of opening any of the VST plugins windows other than > clicking the GUI column for the plugin under the MIDI ports / soft synths > window which seems a bit awkward to me. Agreed. Bit of an oversight. Normally the other MESS synths open automatically right away. But DSSI-VST support presented a problem: When you close a DSSI-VST 'native' GUI window via the window's 'X', you cannot open it again. Same behaviour as in Rosegarden. However in MusE if you stick using to the popup 'show generic/native GUI' menu, it works every time ! Em, thus I wanted to kinda force users to learn that poup menu, so I kept 'em closed at creation. Well, that and the GUIs can be complicated and take time and some may want to work strictly with the generic GUI (which... again... has no program box... sigh). And so on. Here with Native VSTs, we needn't worry too much about all that, so it's do-able. > > There are 3/4 ways I'd expect/like to be able to open the VST etc. plugins > GUI window: > > 1 - When a VST plugin 'track'/object is selected in the arranger you should > be able to either double-click on the plugin name/ title at the top of the > plugins column on the left or right click and select 'Edit'. > > 2 - Double-clicking on any of the synth / VST plugin icons in the arrangers > 'Track Type' column > > 3 - As 1 but in the Mixer window columns too Agreed it should be better. Been studying those columns some more. I have always kinda hated that left-click ports popup menu versus the right-click 'show gui' menu. I think we should unify the two onto the right click menu. Thus it would clear the way to use left-click or double-left-click as 'show native gui', or the fall-back 'show gui'. Also would like to unify several other kinda sloppy menu arrangements. Tim. > > If you can get at least one of those in Tim I'll be even happier! > > Well done Tim! You've made my Christmas! > > :D > > > On Fri, Dec 7, 2012 at 8:02 AM, Tim E. Real <ter...@ro...> wrote: > > > > Feature: Native VST instruments support. > > Now in the SVN trunk. > > > > Here's what I got so far. Try er' out. Remember things may > > change slightly (or wholly?) so let's give a thorough workout > > to weed out any bugs. > > > > Best results are from compiling with the vst sdk. > > > > Featuring: > > True sample-accurate parameter automation! > > Full native GUI support for TOUCH, WRITE modes! > > > > New cmake options for: > > Enabling native vst. > > Enabling true sdk support . > > The vst header path. > > > > Plugins environment variable is currently VST_NATIVE_PATH > > else "/usr/lib/vst:/usr/local/lib/vst". > > > > What should we do there for paths and env var, eh folks? > > > > TODOs: Parameter ranges: fixed at linear 0.0 - 1.0 for now. > > Program categories. Dynamic port changes. > > Plugins correct path and env var? > > No rack effect plugins yet. > > > > And so on... > > > > --------------------------------- > > NOTICE: Plugins vary widely in quality. Some may crash MusE upon startup, > > while using MusE, or particularly most common - > > upon closing MusE. > > Be careful what you put in the plugin directory! > > Advice is to try one-at-a-time, or use the -D > > switch to see what plugin > > might be crashing MusE at startup. > > --------------------------------- > > > > Lemme know if any of them cause trouble. > > I'll take them out back and have a stern talk with them... > > > > Tim. > > |
From: Tim E. R. <ter...@ro...> - 2012-12-08 22:50:39
|
On December 8, 2012 05:39:14 AM Tim E. Real wrote: On December 8, 2012 08:56:59 AM Dan MacDonald wrote: > > Hi Tim! > > > > I've done a clean checkout and it seems you've removed vestige support for > > the moment > -- For the moment just put a vestige header in the vestige directory. OK Re-added it. (Am I being too paranoid about that thing? Just trying to be careful.) Also enabled some older plugins like Highlife and ZR3. Highlife gui freezes MusE but works OK in QTractor. Must check why... Also must fix incorrect or blank name displays especially on these older plugins... Tim. |
From: Dan M. <al...@gm...> - 2012-12-09 13:09:20
|
I've just had a quick play with the latest, vestige-using svn and I was happy to see Noizemaker is working now and I can select presets for it without having to open its plugin window so good work there Tim! One of the biggest showstoppers for the VST support now seems to be (easy) parameter automation. If I add Aspect or Noizemaker to a session, assign it to a MIDI track, open its piano roll then click on the CTRL icon at the bottom of the piano roll I get the MIDI controllers menu and within that there is 'Instrument Defined' with an 'Add' sub-menu that does nothing currently. With both of these synths I would expect to see 100+ parameters I should be able to choose to automate but this doesn't seem to be supported yet. I am looking in the right place here aren't I Tim? I expect its something you've not added yet right? OK I think I've given poor Tim enough to chew on for the next week at least now! :D Thanks Tim! |
From: Tim E. R. <ter...@ro...> - 2012-12-09 23:07:37
|
On December 9, 2012 01:09:13 PM Dan MacDonald wrote: > I've just had a quick play with the latest, vestige-using svn and I was happy to see Noizemaker is working now and I can select presets for it without having to open its plugin window so good work there Tim! > > One of the biggest showstoppers for the VST support now seems to be (easy) parameter automation. If I add Aspect or Noizemaker to a session, assign it to a MIDI track, open its piano roll then click on the CTRL icon at the bottom of the piano roll I get the MIDI controllers menu and within that there is 'Instrument Defined' with an 'Add' sub-menu that does nothing currently. With both of these synths I would expect to see 100+ parameters I should be able to choose to automate but this doesn't seem to be supported yet. > > I am looking in the right place here aren't I Tim? I expect its something you've not added yet right? > > OK I think I've given poor Tim enough to chew on for the next week at least now! :D > > Thanks Tim! > [Deep breath] Sigh. OK Read carefully, here's da situation wif da automation: Short answer: You want the 'Automation' column in the Arranger Track List. There you can assign midi controllers to the synth's parameters, as well as any rack effects the track may possess. Long answer (grab a coffee): If you add a DSSI synth, you will notice that the piano roll midi controller graphs DO list an entire series of available midi controllers for the synth. However, /that/ simply does the same thing as the 'Automation' Track List column. It takes the incoming midi stream and /converts/ it to a floating point stream which modifies the synth's parameters, just as if you adjusted a slider or knob or switch etc. (Keep in mind the 'Automation' Track List column was added quite later on.) But there's a difference with DDSI: It supports an actual assignment scheme, which is *crucial* for reporting to the user what is actually assignable ! Otherwise you stuck reading from a 'cheat sheet' in the manual. VST does *not* have a scheme (at least <= 2.4 dunno 'bout 3) AFAICT. It is the reason when you try for example the fabulous XSynth DSSI (try it!) the midi controller graphs list /two/ additional midi controllers: 5 Glide Rate, and 8 Oscillator Balance. These are /not/ floating point audio 'parameters' like all the others listed - these are true integer midi controllers supported by DSSI. Smart, eh? It let's me report them to users. Now, about the others, the 32NF0 and so on, /these/ are floating point parameters which *I* created to map to the parameters, arbitrarily assigning beginning at NRPN 14bit #0 (that's what the NF means), simply because we had no /other/ mapping scheme at the time, so to get folks up and running. But one problem is that the DSSI synths themselves can respond to certain controllers and not even inform DSSI ! Thus we have no way of knowing whether 99% of DSSI synths support Pitch Wheel or not for example, because they don't report it - they just 'silently' accept it. OK, so about the VST: I've not done this arbitrary 32NF* assigning (yet) because we have true parameter automation midi assignment in the Track List. However, the graphing is a bit weak but getting better. And yes I realize it is desirable to have the midi graphs as well. Yeah been pondering it for a while (before VST). When we have a midi controller stream which is assigned to an audio parameter, should we a): record it only as audio automation graphs (midi data is lost!) b): record it only as midi automation graphs (ironically converted as audio parameters anyway!) c): both Yeah was thinking, should I just dump the incoming midi stream 'as is' into the midi graphs. Advantage is that the true original midi data is preserved. OK now here's the real problem at the moment: Waaay back at the front of the midi *input* driver side, we (blush) actually have *no* support for RPN NRPN controllers, only regular controller7 CCs ! You can /draw/ the graphs but there's no way to /record/ em ! Been studying the situmutation: I /could/ quickly add support (it involves remembering 'current' (N)RPN H/L param numbers and so on) but it pays no regard to what type of instrument is sending and whether the numbers should be interpreted as RPN or NRPN for example. A more elegant solution is... drum roll please... INPUT Instruments In addition to the output instruments that we have now. That is, you tell MusE what kind of instrument is supplying midi input - patches, supported (N)RPN controllers - the whole picture, and *then* we'll talk, because I dunno if I can trust the numbers you're sending me! He he... ** Before I forget, someone once asked about DAISY CHAINING MIDI. I replied that it appears do-able with our Jack midi devices but not ALSA. Yeah been pondering this. I think it would be relatively easy to change MusE from PER-PORT instruments to PER-CHANNEL instruments. And be shown in the midi track info. (Yeah!) That way the physical devices in the single midi 'chain' could be set to different patches and so on. I hope this would help solve the problem. But I wondered about SYSEX support - how does one send SYSEX messages (especially the 'generic' ones GM ON etc) to these individual devices? SYSEX don't have channels. There /is/ a defined midi meta to set the channel for that kind of thing but that's only midi files, not real-time. Cheers. Tim. |
From: Dan M. <al...@gm...> - 2012-12-10 08:04:51
|
Uh oh! On the whole, MusE 2 is shaping up to be significantly more user friendly and with a much nicer workflow than its Linux alternatives but I'm quite concerned about VST automation. I've had a few goes now with no luck and if I understand how I'm supposed to be doing this now it seems very messy in comparison with qtractor and A3's VST MIDI automation so I'm hoping its not too late to get something easier sorted out here. Your long explanation on VSTs vs DSSI plugins went over my head but basically I'd encourage you to look at how easy it is to add VST MIDI param automation to a track under qtractor and try to mimic that as closely as possible under Muse. Of course, qtractor shows the automation within the track instead of having a dedicated display area within its piano roll window like Muse - I'm not bothered about that aspect. Its having to assign a parameter to a controller which I find a messy and confusing process. I'm sorry but you'll have to be a bit more verbose in your instructions Tim if I'm to be successful in trying out the current implementation. Here's how I think it is supposed to work currently: Add your VST plugin in the arranger Click the numbers within the Automation column in the arranger for the VST plugin Find the parameter you wish to automate, then choose its 'Assign' sub menu This is the confusing bit now as I'm presented with a MIDI control window. The 'port' dropdown seems like it shouldn't really be a dropdown as you can't choose anything other than the current port anyway. What about the channel? Do I set that to the same channel as the synth or the MIDI track? Control type - I have no idea but I presume Control7 is a 7bit MIDI controller and Control14 is 14bit and that in most cases people should choose Control7 right? Hi and Lo? What are they for? It seems to me that Lo sets the actual MIDI controller number to assign to but I dunno why its called 'Lo' as no matter what setting I choose for control type 'Hi' never becomes available as a configurable setting. So basically I think all the user should need to do here is set the 'Lo' to the MIDI controller number they want to use for the chosen parameter but its an awfully confusing way to do it. Presuming I have assigned a controller to my parameter, I then go to the piano roll, click 'CTRL', go to the 'Common Controls' submenu, add a the relevant controller, draw stuff, play - nothing! :/ Thanks for your help Tim! On Sun, Dec 9, 2012 at 11:07 PM, Tim E. Real <ter...@ro...> wrote: > On December 9, 2012 01:09:13 PM Dan MacDonald wrote: > > > I've just had a quick play with the latest, vestige-using svn and I was > happy to see Noizemaker is working now and I can select presets for it > without > having to open its plugin window so good work there Tim! > > > > One of the biggest showstoppers for the VST support now seems to be > (easy) > parameter automation. If I add Aspect or Noizemaker to a session, assign > it to > a MIDI track, open its piano roll then click on the CTRL icon at the > bottom of > the piano roll I get the MIDI controllers menu and within that there is > 'Instrument Defined' with an 'Add' sub-menu that does nothing currently. > With > both of these synths I would expect to see 100+ parameters I should be > able to > choose to automate but this doesn't seem to be supported yet. > > > > I am looking in the right place here aren't I Tim? I expect its something > you've not added yet right? > > > > OK I think I've given poor Tim enough to chew on for the next week at > least > now! :D > > > > Thanks Tim! > > > > [Deep breath] Sigh. OK Read carefully, here's da situation wif da > automation: > > Short answer: You want the 'Automation' column in the Arranger Track List. > There you can assign midi controllers to the synth's parameters, as well as > any rack effects the track may possess. > > Long answer (grab a coffee): If you add a DSSI synth, you will notice that > the piano roll midi controller graphs DO list an entire series of > available > midi controllers for the synth. > > However, /that/ simply does the same thing as the 'Automation' > Track List column. It takes the incoming midi stream and /converts/ it > to a floating point stream which modifies the synth's parameters, > just as if you adjusted a slider or knob or switch etc. > (Keep in mind the 'Automation' Track List column was added quite later on.) > > But there's a difference with DDSI: It supports an actual assignment > scheme, > which is *crucial* for reporting to the user what is actually assignable ! > Otherwise you stuck reading from a 'cheat sheet' in the manual. > > VST does *not* have a scheme (at least <= 2.4 dunno 'bout 3) AFAICT. > > It is the reason when you try for example the fabulous XSynth DSSI > (try it!) the midi controller graphs list /two/ additional midi > controllers: > 5 Glide Rate, and 8 Oscillator Balance. These are /not/ floating point > audio 'parameters' like all the others listed - these are true integer > midi > controllers supported by DSSI. Smart, eh? It let's me report them to > users. > Now, about the others, the 32NF0 and so on, /these/ are floating point > parameters which *I* created to map to the parameters, arbitrarily > assigning > beginning at NRPN 14bit #0 (that's what the NF means), simply because > we had no /other/ mapping scheme at the time, so to get folks up and > running. > > But one problem is that the DSSI synths themselves can respond to certain > controllers and not even inform DSSI ! Thus we have no way of knowing > whether 99% of DSSI synths support Pitch Wheel or not for example, > because they don't report it - they just 'silently' accept it. > > OK, so about the VST: I've not done this arbitrary 32NF* assigning (yet) > because we have true parameter automation midi assignment in the Track > List. > However, the graphing is a bit weak but getting better. > And yes I realize it is desirable to have the midi graphs as well. > > Yeah been pondering it for a while (before VST). > When we have a midi controller stream which is assigned to an audio > parameter, > should we > a): record it only as audio automation graphs (midi data is lost!) > b): record it only as midi automation graphs (ironically converted as audio > parameters anyway!) > c): both > > Yeah was thinking, should I just dump the incoming midi stream 'as is' into > the midi graphs. Advantage is that the true original midi data is > preserved. > > OK now here's the real problem at the moment: > Waaay back at the front of the midi *input* driver side, we (blush) > actually > have *no* support for RPN NRPN controllers, only regular controller7 CCs ! > > You can /draw/ the graphs but there's no way to /record/ em ! > > Been studying the situmutation: I /could/ quickly add support > (it involves remembering 'current' (N)RPN H/L param numbers and so on) > but it pays no regard to what type of instrument is sending and whether > the numbers should be interpreted as RPN or NRPN for example. > A more elegant solution is... drum roll please... > INPUT Instruments > In addition to the output instruments that we have now. > That is, you tell MusE what kind of instrument is supplying midi input - > patches, supported (N)RPN controllers - the whole picture, and *then* > we'll talk, because I dunno if I can trust the numbers you're sending me! > He he... > > ** Before I forget, someone once asked about DAISY CHAINING MIDI. > I replied that it appears do-able with our Jack midi devices but not ALSA. > Yeah been pondering this. I think it would be relatively easy to change > MusE > from PER-PORT instruments to PER-CHANNEL instruments. > And be shown in the midi track info. (Yeah!) > That way the physical devices in the single midi 'chain' could be set to > different patches and so on. > I hope this would help solve the problem. > But I wondered about SYSEX support - how does one send SYSEX messages > (especially the 'generic' ones GM ON etc) to these individual devices? > SYSEX don't have channels. There /is/ a defined midi meta to set the > channel for that kind of thing but that's only midi files, not real-time. > > Cheers. Tim. > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Lmuse-user mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-user > |
From: Tim E. R. <ter...@ro...> - 2012-12-10 08:38:43
|
On December 9, 2012 06:07:21 PM Tim E. Real wrote: > Long answer (grab a coffee): If you add a DSSI synth, you will notice that > the piano roll midi controller graphs DO list an entire series of available > midi controllers for the synth. Yikes. I just did some testing on those 32NF* DSSI midi controller graphs and with some synths which have thousands of controls (FreeAlpha DSSI-VST) I noticed two things: 1) When I recently unified the 'Ctrl' popup menus, I made it waaay slower with these thousand-control synths because it now takes a long time to fill up the 'Add' sub-menu. (Clicking on 'Add' used to popup a separate new menu.) 2) The numbering scheme gets outta whack. I noticed the low param numbers go above 127 - like this: 32NF234. Proof that's wrong is when you try to edit that graph and it shows a completely different number like 32NF60. Maybe I forgot to logical AND the low param number with 0x7F... I will take a look. Also Dan I will try to add these controls for VST synths just to get you folks running, manually creating graphs. Thing is that the 32NF* numbers are arbitrary, no way for user to change them. So I'm studying the controller situation. Got some ideas might work quickly. Easiest would be to expand on my 'midi learn' dialog box adding a table, and this is how you would assign (create actually) new controllers available to be shown in the midi controller graphs. You would access the dialog from the 'Ctrl' menu as well as the 'Automation' column menus - which would really clean that whole mess up - thousands of controls gives too many audio automation menu items with those colour boxes and so on. More elegantly I've been aiming to add two new routing types: Midi control and audio control. Route anything anywhere - even say, raw audio data to midi control ports. Robert, this would allow us to route for example audio compressor control outputs to anywhere else, for which you recently expressed a desire. Alas I was hoping to unify audio and midi controllers first but hey, maybe I'll take just a pragmatic approach (we got streams - deal with 'em!) and support the two separate streams. Anyway after that, our much forgotten 'routing' dialog (in the mixer menus) needs a makeover to show all the routes. It's problem ATM is it uses TEXT items. We need to use class Route as the list items, NOT text. Because the class Route has trouble determining the Route type based solely on it's text name (other Routes might have the same text name but be different types.) Once we do that, we're free to list any route types confidently. And bring this routing dialog out of the shadows and more upfront. And give it Bezier curves and so on. I think the OOM team made their router a centerpiece. Makes sense, that and a mixer is where crucial stuff happens. Tim. |