compiled from svn 3307 some hours ago.
Superb work on smashing "note pool empty" bug.
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.
Gigedit bug:DimRgn change event debounce
Re: Gigedit bug:DimRgn change event debounce
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.plusminus wrote:VoiceBase::Render(): entered with playback_state_end, this is a bug!
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.
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 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)
Re: Gigedit bug:DimRgn change event debounce
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
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