Gigedit bug:DimRgn change event debounce

You're new to the LinuxSampler world? You don't know where to start and nothing works? Here's the place to ask for help.
Post Reply
plusminus
Newbie
Posts: 22
Joined: Tue Jun 21, 2016 3:32 am

Gigedit bug:DimRgn change event debounce

Post by plusminus » Fri Jul 14, 2017 2:33 am

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.

User avatar
cuse
Developer
Posts: 366
Joined: Wed Jan 23, 2008 10:07 pm
Location: Germany

Re: Gigedit bug:DimRgn change event debounce

Post by cuse » Mon Jul 17, 2017 2:27 pm

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.

plusminus
Newbie
Posts: 22
Joined: Tue Jun 21, 2016 3:32 am

Re: Gigedit bug:DimRgn change event debounce

Post by plusminus » Thu Jul 20, 2017 6:22 pm

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

Post Reply