Audacity Forum

Keep us posted on when you can commit.

I don't know if you ever tested really long tracks with Time Scale, but with current SVN it seems a 50 minute stereo track with extreme settings can take getting on for 90 minutes to complete (but doesn't crash). See:
http://forum.audacityteam.org/viewtopic ... 759#p98759


Thanks


Gale

I'm still working on the vst sbsms sampler (which is turning out to be quite interesting). It will take some time as I keep coming up with ideas as fast as I implement them (which require significant changes to the library itself). I am considering permanently branching the audacity/sampler library code for various reasons (the size of the library source and the binary is quite a bit larger, for one thing). Regardless, I'll try to focus on committing to audacity in some form or another as soon as possible. Sorry for the unwarranted delay - is there a release scheduled which I should aim for?

I decided I will definitely branch. Sourceforge and audacity will share a pared down branch, and the sampler will have its own branch (which I don't have any plans for releasing as source any time soon). This will make me and audacity and the sampler much happier, but it may be a little annoying to manually merge changes in the future (this should be rare and mostly limited to bug fixes, though). I will completely remove the silly sbsmsplay/wxsbsmsplayer programs, and only support the command line sbsms utility, audacity, and the sampler.

I will devote my time to paring down what I have to a lean version for audacity until I submit. This should be a few days - for real this time, now that I actually have a solid chunk of time and a plan.

I ended up not quite branching - the common code will become the new libsbsms-2.0.0, and the fancy gadgetry will all be relegated to the unreleased sampler code.
It's tested in audacity and basically ready to submit, but I still haven't done so because I want to resolve a quality issue first. It should be very soon, now.

otey wrote:It should be very soon, now.

Good work otey - I can't wait to try it out.

Has the patch been submitted/applied?

This a a BLOCKING bug:
Bug 172
which means that a new Audacity stable release is not going to be released until it (an a couple others) get resolved.

Addressing the quality issue unexpectedly required me to make some drastic changes to the core code which my last chunk of free time didn't allow me to finish. I still need another round of changes to finalize it, but I have settled on a method. I can pull some free time out of the ether and push to get this done in a matter of days. I admittedly don't have the best recent track record on finishing up, though - so I'm willing to just submit my unfinished work (which fixes the bug but doesn't incorporate my most recent improvements) if others deem it necessary. I would very much prefer to finish my planned release before submitting, though.

Is there a planned schedule for the next release?

otey wrote:Addressing the quality issue unexpectedly required me to make some drastic changes to the core code which my last chunk of free time didn't allow me to finish. I still need another round of changes to finalize it, but I have settled on a method. I can pull some free time out of the ether and push to get this done in a matter of days. I admittedly don't have the best recent track record on finishing up, though - so I'm willing to just submit my unfinished work (which fixes the bug but doesn't incorporate my most recent improvements) if others deem it necessary. I would very much prefer to finish my planned release before submitting, though.

Is there a planned schedule for the next release?

Hi Clayton,

Realistically this bug isn't likely to hold up 2.0 in the near future. If we still want to incorporate Device Toolbar into Mixer Toolbar so that Mixer Toolbar displays Win Vista/7 inputs (Bug 11) that alone needs a lot of work and testing. Also it seems at the moment we may be waiting to fix all/most of the P2s before releasing a final Beta (1.3.13).

That said, it usually makes sense to commit bug fixes as soon as possible, given the exigencies of working on bugs in limited spare time. What are the residual quality issues? We should know what those are, either for testing the bug-fix-and-quality-fix, or for logging the quality issue as a bug if we just commit the fix to Bug 172 without addressing the quality issue.



Gale

The quality issue shows up most noticeably as occasional audible transient artifacts or undesired amplitude modulation in closely spaced tones when samples are timestretched. I could just tweak some parameters so that the frequency is better resolved and these artifacts go away, but then the time representation is annoyingly smeared out.

I managed, in the last week or so, to implement an improvement that satisfies me for the time being. If anybody is interested, the idea is to attempt a "trial" synthesis based on a high frequency resolution analysis, and then to compare high time resolution analyses of the input audio and the trial synthesis, and finally to adjust the amplitudes so that the modified trial roughly matches the input. I was pleased to find that this new method does in fact work "better" than before on all of my test cases - i.e. it has better time resolution without as many artifacts from low frequency resolution. Intuitively I expected the new approach might introduce more artifacts than it corrects, but it seems quite robust. It is naturally more computationally expensive, but it shouldn't be too bad.

I'll do my best to optimize/test/fine tune a few things and get this thing submitted before too long.

Hi Clayton,

otey wrote:I admittedly don't have the best recent track record on finishing up, though - so I'm willing to just submit my unfinished work (which fixes the bug but doesn't incorporate my most recent improvements) if others deem it necessary. I would very much prefer to finish my planned release before submitting, though.

Multiple small commits that fix issues independently are preferred over big commits that make multiple improvements and fixes.
Please do commit the fix when you get to a point where things compile and aren't breaking.
It's been more than a few months now and from what I've seen this bug is just a couple lines of code to fix.
I can give you a patch if you like.