From: Tim E. R. <ter...@ro...> - 2011-11-21 23:49:27
|
Hey guys must let you know what I'm doing for last few days. I fixed annoying problems with dssi synth and plugin guis not remembering settings, and native their controls not updating the generic ones. Was an audio processing engine problem. Off tracks, or unconnected tracks or stopped Wave Tracks or tracks with bypassed plugins would not be processed, so the OSC control input FIFO was not being read, so the control values were not saved. Now the controls work all the time and remember, even if the track is completely off! --- So... while in the audio engine, I diagnosed a long-time annoying issue: *Aux* Tracks! Yep, flaky as heck, and success depended on their position in the track list. And depended what they were routed to. I'm applying some fundamental audio engine fixes here, now. Those Aux Tracks sure made it really tricky. It took me a verrry deep, long session to realize what was wrong, test, and form solutions. To make them work properly, I had to: a) Install an anti routing feedback mechanism so that things like Group1 -> Group2 -> Group1 do not cause their processing (including controls) to stop or audio feedback. Planned this long ago. b) Think of Aux Send Knobs -> Aux Tracks as just another routing scheme. Thus, similar to other tracks, when it is time to process an Aux Track, it must first cause all aux-aware tracks to process so that all the aux send audio data has been pre-gathered. c) Process all Aux Tracks first, before all others. d) Install a Track::auxRefCount which keeps track of how many Aux Track routes ultimately feed the track. During step c), defer processing all tracks fed (eventually) from an Aux Track. All such tracks cannot process their aux send corresponding to that Aux Track. It's a circular dependency! Well, step d) is under way. Wish me luck. It's been another tough one. "Specifications may change and probably will." --- Robert there's a conflict with our DoubleChorus and PanDelay IDs 1051 + 1052. There are already two ladspa plugins with those numbers: Cmt lpf and hpf It was said on LAD that one should never depend on those numbers alone. Meaning it's OK that two plugins with the same ID show up in our list. But I noticed trouble. The guis were mixed up - the controls were wrong. Must check more, can't reproduce now. Tim. |
From: Tim E. R. <ter...@ro...> - 2012-02-08 07:14:01
|
Hey. No commit yet, just working on... Fixing some controller issues especially initialization. --- Fixed Fluid and Fluidsynth processEvent(). Don't return true for controllers. Was causing multiple send attempts. --- Fixed Fluid pitch bend input. --- Now force send controller events ALWAYS during play, even if redundant. --- Working on sending controllers during seek mode, very tricky... But after my last commit, I really don't want to go back to sending all those redundant values for every little seek increment. So it involves making sure events are sent when jumping across event borders, even redundant events. And will require modifying the 'Midi -> Init Instrument' menu command to send out all current valid controller values. It currently doesn't - only a few. It's all I can do, I don't want to revert back to constantly sending them while seeking in long empty stretches where the previous event was way back, you'll just have to click 'Midi -> Init Instrument'. Opinions? Like/hate it? --- Song load was not restoring some synth parameters like volume. Crud... Long ago in MidiPort::setMidiDevice() I told it not to send any controller values to synths, to use the midiState sysex and/or float initParams (for dssi) instead. But actually some synth parameters are not stored in the midiState sysex. Like some synth volumes. Or more important, midi-enabled parameters which can't be moved into midiState, which are just sent to the synth and aren't 'shadowed', such as fluidsynth volume CC control. So I reluctantly had to revert two lines in MidiPort::setMidiDevice() to send all the controllers to the synths as well regular midi devices. Ugh. I never liked it. It sends a lot of stuff to the synths. There can be hundreds, even thousands of parameters. It revealed a too-low EVENT_FIFO_SIZE = 256 in synti/libsynti/gui.h I'll have to increase that, for Deicsonze to work. Also Deicsonze crashes MusE on close when its Plugin list is cleared. But more fundamentally, the purpose of my code in MidiPort::setMidiDevice() upon initialization was: If an initial value for this midi controller, on this midi channel, in the song (in a part) is found, send it. Else if the instrument's midi controller has a defined initial value, send it. Else do nothing, send nothing, leave the controller alone. This works well for our definable MusE instruments, where we can set no initial controller value (UNKNOWN) and so have relatively few initial values being sent out at song load. But the synths are a wee bit different. When we ask for the list of their available controllers and their initial default values, some of the synths have no concept of UNKNOWN values, so we end up retrieving non-unknown initial values for the entire list of controllers, which can be in the thousands. That's why I say I never liked sending the initial synth controllers, in MidiPort::setMidiDevice(). Not to mention, these initial values end up /competing/ with the midiState sysex and are unfortunately IIRC sent /after/ the midiState, overriding it. That's wrong so I'll have to fix that. Recall I said long ago we have a few competing 'initial value' mechanisms. Well, there's two of 'em. And then we have dssi synth float and string Params and, with the flick of a define in dssihost.cpp, dssi-vst chunk support. Pass the Aspirin, please. Yapping too much? All for now. Cheers. Tim. |
From: Geoff B. <ge...@la...> - 2011-11-21 23:57:03
|
On 11/22/2011 10:48 AM, Tim E. Real wrote: > Hey guys must let you know what I'm doing for last few days. > > I fixed annoying problems with dssi synth and plugin guis not > remembering settings, and native their controls not updating > the generic ones. > > Was an audio processing engine problem. > Off tracks, or unconnected tracks or stopped Wave Tracks or tracks with > bypassed plugins would not be processed, so the OSC control input FIFO > was not being read, so the control values were not saved. > Now the controls work all the time and remember, even if the track is > completely off! > > **snip** great work Tim - sounds like a biggie - looking forward to the commit ;) g |
From: Florian J. <flo...@we...> - 2011-11-22 00:32:12
Attachments:
flo.2.patch
|
Am 22.11.2011 00:48, schrieb Tim E. Real: > Hey guys must let you know what I'm doing for last few days. > > I fixed annoying problems with dssi synth and plugin guis not > remembering settings, and native their controls not updating > the generic ones. > > Was an audio processing engine problem. > Off tracks, or unconnected tracks or stopped Wave Tracks or tracks with > bypassed plugins would not be processed, so the OSC control input FIFO > was not being read, so the control values were not saved. > Now the controls work all the time and remember, even if the track is > completely off! > > --- > So... while in the audio engine, I diagnosed a long-time annoying issue: > *Aux* Tracks! Yep, flaky as heck, and success depended on their position > in the track list. And depended what they were routed to. > > I'm applying some fundamental audio engine fixes here, now. > Those Aux Tracks sure made it really tricky. > It took me a verrry deep, long session to realize what was wrong, > test, and form solutions. > > To make them work properly, I had to: > > a) Install an anti routing feedback mechanism so that things like > Group1 -> Group2 -> Group1 > do not cause their processing (including controls) to stop or audio feedback. > Planned this long ago. > > b) Think of Aux Send Knobs -> Aux Tracks as just another routing scheme. > Thus, similar to other tracks, when it is time to process an Aux Track, > it must first cause all aux-aware tracks to process so that all the aux send > audio data has been pre-gathered. > > c) Process all Aux Tracks first, before all others. > > d) Install a Track::auxRefCount which keeps track of how many Aux Track routes > ultimately feed the track. During step c), defer processing all tracks > fed (eventually) from an Aux Track. All such tracks cannot process their aux > send corresponding to that Aux Track. It's a circular dependency! > > Well, step d) is under way. Wish me luck. It's been another tough one. > "Specifications may change and probably will." > > --- > Robert there's a conflict with our DoubleChorus and PanDelay IDs 1051 + 1052. > There are already two ladspa plugins with those numbers: Cmt lpf and hpf > > It was said on LAD that one should never depend on those numbers alone. > Meaning it's OK that two plugins with the same ID show up in our list. > > But I noticed trouble. The guis were mixed up - the controls were wrong. > Must check more, can't reproduce now. > > good that someone is finally fixing the audio stuff... what you wrote sounds like black magic, but i don't know anything about how muse does audio ;) tim, while you're at it, please run valgrind on muse, then do the following: * create two wave tracks * create a new wave part on the first * import some file into the second * move the imported part around, both to legal and illegal destinations and release the mouse button * open the wave editor, edit it a bit you'll get PLENTY of valgrind errors. most about invalid reads/writes. one problem is that the arranger seems to call items.clearDelete() while moving. the moved items are stored in the "moving" list. Upon items.clearDelete() however, the entries in "moving" are invalid, as they just got freed (moving is a subset of items). i tried to fix this by repopulating moving with the NEW citems, but it doesn't work :/ i've attached the patch. also, muse seems to continously do invalid writes/reads even when there's no user interaction. if you just create a wave track and let muse alone, then at some point valgrind will complain that more than 100000 errors happening. "go fix your program". i think we really should ;) then there's that "import a wave file, split it, close muse, segfault" bug... also, the global cut, insert and whatnot functions don't work on wave tracks. can you take a look on this as well if you're done with the above ;)? greetings flo > Tim. > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > > |
From: Robert J. <spa...@gm...> - 2011-11-27 11:08:50
|
2011/11/22 Florian Jung <flo...@we...>: > Am 22.11.2011 00:48, schrieb Tim E. Real: <...> >> --- >> Robert there's a conflict with our DoubleChorus and PanDelay IDs 1051 + >> 1052. >> There are already two ladspa plugins with those numbers: Cmt lpf and hpf >> >> It was said on LAD that one should never depend on those numbers alone. >> Meaning it's OK that two plugins with the same ID show up in our list. >> >> But I noticed trouble. The guis were mixed up - the controls were wrong. >> Must check more, can't reproduce now. Is this still an issue? Will have to try it. Does the DoubleChorus and PanDelay work now? Wasn't there some build problem with them... <...> > also, the global cut, insert and whatnot functions don't work on wave > tracks. can you take a look on this as well if you're done with the above > ;)? I fixed this some weeks ago, isn't it working for you Florian? Regards, Robert |
From: Florian J. <flo...@we...> - 2011-11-27 13:48:12
|
Am 27.11.2011 12:08, schrieb Robert Jonsson: >> also, the global cut, insert and whatnot functions don't work on wave >> tracks. can you take a look on this as well if you're done with the above >> ;)? >> > I fixed this some weeks ago, isn't it working for you Florian? > yep, is fixed. haven't noticed, thanks :) greetings flo > Regards, > Robert > > |