Menu
▾
▴
Re: [Lmuse-developer] [ lmuse-Feature Requests-3515971 ] Support for DSSI effects
|
From: Jeffrey H. <jhu...@ya...> - 2012-04-19 03:00:01
|
> Whereas the descriptions are the long-form identifiers. > They can be quite long, they don't really belong as a track name. Oh no, I wouldn't do that :-P Descriptions must be 32(?) characters or less, most hosts start overwriting past the bounds of the array into other memory... I actually ran into huge problems with that early on, I was appending "(Powered by LibModSynth)" to the end of my LADSPA descriptions, and getting strange behaviours and erratic crashes, inexplicable segfaults... > I'd uniquely name them to be safe... I'll put that on my shortlist of things to do. I hesitated to do that at first because it meant having to customize each plugin's Makefile.am in ways that I didn't want to, but I'll go ahead and do that now before any developers start picking up my library... > I remember in old LAD/Jack discussions that identifying by LADSPA > unique ID number is a bad idea. We don't. ...and... > (After all, how would they know we took those IDs unless we tell them? > Is there a 'master' LADSPA registry somewhere? ladspa.org?) I'm sure some plugin developers have totally screwed up the rotation over the years by picking 2/3/4 digit numbers that aren't very random, like picking 666 for their heavy-metal guitar distortion plugin, etc.... It wouldn't matter if there's a registry or not because I'm sure it wouldn't have anywhere near 100% participation. There's an official upper limit for plugin UUIDs, and it's a fairly high number, like 8 or 9 digits; When running "perl build.pl --fork" from my build system, a very, very random UUID is generated by adding several random numbers to each other... but coming from a network security background I probably appreciate things like UUIDs and MD5 hashes more than most people... The average person surely picks things like 1000, 1234, 6969, etc... I'll report back whenever I've had a chance to fix all of my LADSPADescriptor->Labels, that may very well fix it... Thanks, Jeff ________________________________ From: Tim E. Real <ter...@ro...> To: lmu...@li...; spa...@gm... Sent: Wednesday, April 18, 2012 9:58 PM Subject: Re: [Lmuse-developer] [ lmuse-Feature Requests-3515971 ] Support for DSSI effects On April 17, 2012 6:07:38 AM Jeffrey Hubbard wrote: > > Hm, not using your GIT yet so no LMS plugins. > > But no trouble with Calf plugins. > > Tried Calf Organ synth, with Calf Flanger, Chorus, and two instances of > > Delay in the rack. > > I assume you're using the CALF effect plugin DSSI variants, I couldn't see > the plugin format specified in the screenshot. I looked through the > src/calf/ladspa_wrap.h file, and I saw that they don't have the > LADSPA_PROPERTY_INPLACE_BROKEN > property, but they conditionally have the > LADSPA_PROPERTY_HARD_RT_CAPABLE > property. Might this be a factor? > > >So I'm guessing, timing issue somehow? > > That's what I was thinking, but I'm not quite sure how. Mm, don't think so. This is more of a gui loading issue, right? Do you still get those exact same OSC errors as before? Then I believe something would still be fishy with our oscMessageHandler which I just tried to fix ... Errors didn't look right. Looked like timing within the routine. But I optimized it. Not enough? ... [snip] > > Also, there is one possible area of contention that the DSSI developers > warned me about; All of my plugins use the following label: > LADSPADescriptor->Label = "LMS"; > The GUI's ELF binary much match the name of the label or the GUI > fails to launch. I made them all the same for the sake of simplicity, but > the DSSI developers told me they should be unique. Whoa, hang on folks. Robert has made a change which replaces the synth names (the displayed track name) with their descriptions. Sorry for the CC! I think it really ought to be names. The names are meant to be nice short, and unique, succinct identifiers. Whereas the descriptions are the long-form identifiers. They can be quite long, they don't really belong as a track name. (Granted, the user can enter any long track name they want.) > I have not fixed it yet > because it didn't seem to be causing any problems in any of the hosts I had > tried it in. Do you think that could be part of the problem? IIRC In our song files we store the library name and the plugin name (but not description). Then when loading the song we use them to search for plugins. Probably taken together that is why MusE can distinguish LMS plugins. Now, the trouble starts when you put all your plugins into a library ! The single library would be ex. LMS_plugins, and they'd all be named LMS. MusE would not be able to distinguish them, I believe. I'd uniquely name them to be safe... At least you're forced to have your own unique library name. Why not take it a step further with unique names for safety... I remember in old LAD/Jack discussions that identifying by LADSPA unique ID number is a bad idea. We don't. Case in point: Robert I mentioned a while back that two of MusE's built-in plugin ID's are 'stolen' by external plugins: 1051 + 1052. FIXME. (After all, how would they know we took those IDs unless we tell them? Is there a 'master' LADSPA registry somewhere? ladspa.org?) Why have I always assumed that all plugin IDs have to be four-digits? Jeff I noticed your plugins use a sort of full UUID. I've never seen before. Wow, just checked, Calf, too. So there's a good solution to our built-in plugin problem, big unique IDs. Must remember to revisit and change it. But the name of the ui file must change too... Thanks. Tim. > > Thanks, > Jeff ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Lmuse-developer mailing list Lmu...@li... https://lists.sourceforge.net/lists/listinfo/lmuse-developer |