Page 1 of 1

Gigedit bug:DimRgn change event debounce

Posted: Fri Jul 14, 2017 2:33 am
by plusminus
compiled from svn 3307 some hours ago.
Superb work on smashing "note pool empty" bug. :D
Ok, so I fired up linuxsampler and loaded from an instrument i made on gigedit.
edit instrument via gigedit.
I choose to edit the sample start offset of a sample and got this:

DimRgn change event debounce END
DimRgn change event debounce BEGIN (0x7f6211504700)
DimRgn change event debounce END
DimRgn change event debounce BEGIN (0x7f6211504700)
DimRgn change event debounce END
DimRgn change event debounce BEGIN (0x7f6211504700)
DimRgn change event debounce END
DimRgn change event debounce BEGIN (0x7f6211504700)
DimRgn change event debounce END
DimRgn change event debounce BEGIN (0x7f6211504700)
VoiceBase::Render(): entered with playback_state_end, this is a bug!

As it all occurs, there would be small pauses in sound.
Still i was able to move forward on any changes to sample start without random quits or crashes.

Re: Gigedit bug:DimRgn change event debounce

Posted: Mon Jul 17, 2017 2:27 pm
by cuse
plusminus wrote:VoiceBase::Render(): entered with playback_state_end, this is a bug!
Yeah, the problem with this one is that the sample you are using is long, so disk streaming is enabled for this sample, and disk streaming however always requires the starting portion to be cached in RAM so that the sampler can playback from RAM immediately without having to wait for the slow disk thread to actually react and deliver the audio stream. And right now the sampler simply caches the first portion of any disk streaming sample starting always at sample point 0, regardless what you are setting as sample start offset. So sample start offset parameter works as long as you don't set it too high, otherwise you will see the error message you got. In this case you might simply increase the amount of samples being cached by the sampler, which is a compile time option. That will increase the amount of RAM being used, but you will be able to use your (probably quite huge) sample start offset.

I know, that workaround is inconvenient, but taking the precise sample start offset parameter in account for the mentioned caching is simply not implemented yet. Most probably because very large sample start offsets are not very frequently used in practice, and like I said, it works with small sample start offsets already.
plusminus wrote:DimRgn change event debounce END
DimRgn change event debounce BEGIN (0x7f6211504700)
DimRgn change event debounce END
DimRgn change event debounce BEGIN (0x7f6211504700)
DimRgn change event debounce END
DimRgn change event debounce BEGIN (0x7f6211504700)
DimRgn change event debounce END
DimRgn change event debounce BEGIN (0x7f6211504700)
DimRgn change event debounce END
DimRgn change event debounce BEGIN (0x7f6211504700)
That's unrelated to this issue. It is simply a debugging message left over for an optimization in gigedit which substantially increased its responsiveness on large gig sounds. So these are neither warnings nor errors and will probably be removed soon completely.

Re: Gigedit bug:DimRgn change event debounce

Posted: Thu Jul 20, 2017 6:22 pm
by plusminus
Thanks for looking into it.
The samples used are percussions and seem to be affected when any parameter is altered.
As you can hear in the video, the sound gets cutoff too.
https://youtu.be/OaOYPkr9q1c