linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

Re: [Linuxsampler-devel] cancel release on note on?

[Vladimir S. <ha...@gm...>]

Mark,

If i understand what you mean by "sync" correctly . . .
How is playing two notes in sync different from playing one note?
In other words, it when the second note is triggered we could just
figure out the parameters that need to be brought fromt he first note
to the second and then we could just start playing the second note and
not play the first one anymore.
But clearly for some instruments it is not going to work well because
the form of the wave could change dramatically in time. So playing two
notes of the same but starting from different position is in fact more
like playing two different notes. So you can't really "sync" them up .
. .

Regards,
Vladimir

Re: [Linuxsampler-devel] cancel release on note on?

[Mark K. <mar...@gm...>]

On Sun, 5 Dec 2004 15:23:32 -0500, Vladimir Senkov <ha...@gm...> wrote:
> Hi Mark,
> It's been awhile, nice to hear from you again! :)

You too.

> 
> > Point in case. Hit a note at 500Hz. Hit the same note exaclty 1 second
> > later. Numerically the two would cancel each other. The first is going
> > up while the second is going down, in sine wave terms. In the piano
> > they do not. The second note always adds to the mix. So, either the
> > first note gets synced to the second or the second to the first, but
> > something must be happening physically.
> 
> Modelling the "real" hammer hitting the "real" string is not easy and
> i don't think we have enough information from the sample file to do
> that.

No, that's all far more complicated than I was intending. I was more
thinking that playing two notes of the same note should be synced. If
note 1 is already playing, and then note 2 is struck (the MIDI event)
then look at the fundamental frequency of these notes and delay the
start of the second note's samples until they would play 'in sync'
with the first note's samples. In this way I was thinking the first
and second note would be more 'supportive' of each other, and in some
ways more like I'm guessing the real string works.

This works for the case where the first note is loud and the second is
soft. However, when we turn it around it's not so clear what to do. If
you want the two to be in sync, then do you play the second one a bit
late again? Or do you play it right away?

My thought is to play them all second notes just a bit late to
guarantee sync between any notes of the same value.

this is all programming trick. I'm not talking about changing anything
fundamental here. All we need to know is the apparent fundamental
frequencies of the notes, but even this may not be obvious, or may be
weird when we add tuning to the tool sets.

- Mark

I think

Re: [Linuxsampler-devel] cancel release on note on?

[Vladimir S. <ha...@gm...>]

Hi Mark,
It's been awhile, nice to hear from you again! :)

> Point in case. Hit a note at 500Hz. Hit the same note exaclty 1 second
> later. Numerically the two would cancel each other. The first is going
> up while the second is going down, in sine wave terms. In the piano
> they do not. The second note always adds to the mix. So, either the
> first note gets synced to the second or the second to the first, but
> something must be happening physically.

Modelling the "real" hammer hitting the "real" string is not easy and
i don't think we have enough information from the sample file to do
that.
I think what happens here is not trivial. For example, let's make a
very simple case: a perfect hammer hits a perfectly idle string right
in the middle (note in a real piano it's not in the middle at all for
most strings). Let's say for whatever reason the string ends up in a
perfect sine at 400Hz. Let's say there is a certain amplitude A to
this sine. So every point of the string moves at the speed of
800A/sec.
But do we mean by "hits"? In reality, hammer's speed is probably in
the same order as 800A/sec if not slower!. Hammer is also not small,
so it hits the string in a relatively large area so that area will not
be in a perfect sine. But more importanly for how long is the hammer
attached to the string while hitting it? And what's going to happen
during this time? If hammer hits the string in the middle, string in
fact becomes two strings each likely to produce a sine at 800Hz rather
than 400.

Same thing is likely to happen at the time any subsequent triggering.

So as far as "real" things we are trying to do my understanding is that:
1) In most samplers (GS included) if i play a note, apply sustain,
release the note, then release sustain, then quickly reapply it, the
note will go out of release back into sustain. That's been well tested
and please correct me if i'm wrong because i firmly believe it :)
2) At the same time, if i play a note,  then release it and quickly
play it again . . . we have differences in implementation.
So the issue is what if the first note in release stage still sounded
richer than the second note. I think it really comes down to how long
the release stage is and how likely is this to happen.
Technically, i think it is "more correct" to treat case number 2 the
same as case number 1. I think that physically when the damper comes
down it affects the first sine existing in the string much more so
then a hammer hitting it. Why? Because if it's larger area and longer
time of contact. In other words, it's designed to do just that, reduce
the amplitude of the wave asap.
Hammer has more energy to it, but that just basically separates the
string into two for a very short period of time and doesn't kill the
initial vibration.

This is all getting interesting when we consider polination between
strings. In other words, it is clear that on a real piano if i hold A3
for a very long time (to the point where it's silent) and then hit A4
very loudly and immediately release A4 i'll now hear A3 again :)
As far as i know, none of the samplers do any of that yet.
But some of those "digital pianos" do from what i hear (from
unreliable sources :).

-- 
Regards,
Vladimir

Re: [Linuxsampler-devel] cancel release on note on?

[Mark K. <mar...@gm...>]

On Sun, 05 Dec 2004 19:01:28 +0100, Andreas Persson
<and...@lk...> wrote:
> Mark Knecht wrote:
> 
> >    Speaking logically only, and not musically or even about GSt or LS
> > specifically, I think it depends on what sort of instrument you are
> > modeling.
> 
> Yes, I guess that's why the "Piano release mode" in a gig file is optional.
> 
> > If the instrument is something physical where-in the second
> > event uses the same physical entity to make the sound, then the second
> > event should override the first. The quiet note replaces the loud
> > note. This is the way a synth with limited oscillator count would work
> > and probably the way GSt works when doing voice stealing.
> 
> If there are enough voices, GSt will play the release of the loud note
> along with the quiet note.
> 
> 
> 
> >    However the piano is difficult. Playing a second note on middle C
> > does not eliminate the first note. (sustain pedal held) The second
> > note is additive, and additive in a non-intuitive way. Actually,
> > whatever the effect of the first and second events are, I would say
> > they both end at the same time. (Again, sustain pedal held.) I don't
> > think the loud note finishes any sooner than the soft note, does it?
> > In fact the soft note might actually finish sooner implying velocity
> > effects the overall length of the envelope.
> 
> Just to be sure, note that the case we've been discussing is not when
> the sustain pedal is being held. Instead: The second note comes so close
> to the note-off of the first that the first note has not finished its
> release yet. Then, with current LS, the first note will give up its
> release and continue to play at its current volume together with the
> second note.

OK, I think I missed that. With a piano this window of time is pretty
small. I guess what you are talking about really is a bug if it does
what I think you are saying it does. The first note must just die away
or you run out of notes much more quickly.

The part I'm not sure I understand from this email is whether the
first note is still using it's sample base, or did it start using the
second note's sample base? Clearly it must use its own samples since
it may be from a different velocity group. I think it probably does.

> 
> When the sustain pedal is held, I think both GSt and LS will handle all
> note-on events as separate events that run independently until their
> respective samples finish (or the sustain pedal is released). An
> exception to this is if "Self mask" option is enabled. Then, a louder
> note will kill a playing quiet one, to preserve polyphony. This feature
> is not yet in LS.

I think that possibly LS should try to improve on GSt's usability. I
run into problems with GSt all the time where the addition of notes
causes the overall mix to get to loud and hence it distorts. This
doesn't happen as quickly when you mix loud and soft notes, but if you
mix all loud notes then you end up with too much volume and the mix
bus distorts. (numerically)

Possibly some sort of soft compressor in the output stages of LS would
help a lot in this area.

> 
> The non-intuitive addition you mention, was an interesting thought. I
> don't think GSt has any support of it.
> 

Actually I had a much more radical thought about what the 'right' way
to do some of this when we are talking about piano modeling. Again, my
thinking initially was about the case where the sustain pedal is held,
but some of it applies even without sustain.

If we consider the piano where there is only a single middle C element
(1 or more strings struck together) then I think a couple of things
possibly happen:

1) Since there is only one string to vibrate then there is only one
'sample set' to play? Maybe a soft second note is really just a
modification of the existing (louder) note's envelope? I'm not totally
convinced of this since the second soft note may have significant
harmonics in it's initial samples that we wouldn't want to miss, at
least in certain cases.

2) Even if you decide that there is a second sample set to play, in
the real piano the two must be sync locked to each other. The string
is vibtrating and the second strike (or probably more accurately the
lower volume strike) must get in sync with the first (louder) strike.
I.e. - there is only one way to vibrate the string at that frequency.
Since both strikes account for creating the same frequencies. (I
think...)

Point in case. Hit a note at 500Hz. Hit the same note exaclty 1 second
later. Numerically the two would cancel each other. The first is going
up while the second is going down, in sine wave terms. In the piano
they do not. The second note always adds to the mix. So, either the
first note gets synced to the second or the second to the first, but
something must be happening physically.

Is there an opportunity to make a better sounding LS by addressing
this idea somehow?

- Mark

Re: [Linuxsampler-devel] cancel release on note on?

[Andreas P. <and...@lk...>]

Mark Knecht wrote:

>    Speaking logically only, and not musically or even about GSt or LS
> specifically, I think it depends on what sort of instrument you are
> modeling.

Yes, I guess that's why the "Piano release mode" in a gig file is optional.

> If the instrument is something physical where-in the second
> event uses the same physical entity to make the sound, then the second
> event should override the first. The quiet note replaces the loud
> note. This is the way a synth with limited oscillator count would work
> and probably the way GSt works when doing voice stealing.

If there are enough voices, GSt will play the release of the loud note 
along with the quiet note.

>    However the piano is difficult. Playing a second note on middle C
> does not eliminate the first note. (sustain pedal held) The second
> note is additive, and additive in a non-intuitive way. Actually,
> whatever the effect of the first and second events are, I would say
> they both end at the same time. (Again, sustain pedal held.) I don't
> think the loud note finishes any sooner than the soft note, does it?
> In fact the soft note might actually finish sooner implying velocity
> effects the overall length of the envelope.

Just to be sure, note that the case we've been discussing is not when 
the sustain pedal is being held. Instead: The second note comes so close 
to the note-off of the first that the first note has not finished its 
release yet. Then, with current LS, the first note will give up its 
release and continue to play at its current volume together with the 
second note.

When the sustain pedal is held, I think both GSt and LS will handle all 
note-on events as separate events that run independently until their 
respective samples finish (or the sustain pedal is released). An 
exception to this is if "Self mask" option is enabled. Then, a louder 
note will kill a playing quiet one, to preserve polyphony. This feature 
is not yet in LS.

The non-intuitive addition you mention, was an interesting thought. I 
don't think GSt has any support of it.

/Andreas

Re: [Linuxsampler-devel] cancel release on note on?

[Mark K. <mar...@gm...>]

On Sun, 5 Dec 2004 15:26:10 +0100, Christian Schoenebeck
<sch...@so...> wrote:
> Es geschah am Sonntag 05 Dezember 2004 15:22 als Andreas Persson schrieb:
> > Christian Schoenebeck wrote:
> > > ProcessControlChange() only handles the sustain pedal case.
> > > ProcessNoteOn() handles the case when the same key was triggered
> > > instantly after releasing the same key. So this make sense.
> >
> > Sorry for being so stubborn, but I'm not sure I understand when the
> > second case adds any realism?
> 
> There's nothing to excuse, doubts are often productive.
> 
> I guess you don't see a realism, because you assume the 2nd key trigger causes
> a new voice of approx. the same amplitude or even higher than the first one.
> 
> But imagine the following case: you trigger key C3 the first time with a
> velocity of 127, then you release key C3 and immediately after that press C3
> again, but this time with a velocity of 1.
> 
> If we do what you claimed and remove those lines, you will hear nothing on the
> 2nd key trigger. With current implementation though you still here the first
> voice. Which makes sense, doesn't it?
> 
> > > Again, we can make that a compile time option if you like.
> >
> > OK, but what will be the default? :)
> 
> I vote against that being the default behaviour. But of course if I'm alone
> with that opinion I accepted it even as default behaviour.
> 
> CU
> Christian
> 

Hi,
   Fairly long time since I've posted much.

   Speaking logically only, and not musically or even about GSt or LS
specifically, I think it depends on what sort of instrument you are
modeling. If the instrument is something physical where-in the second
event uses the same physical entity to make the sound, then the second
event should override the first. The quiet note replaces the loud
note. This is the way a synth with limited oscillator count would work
and probably the way GSt works when doing voice stealing.

   However the piano is difficult. Playing a second note on middle C
does not eliminate the first note. (sustain pedal held) The second
note is additive, and additive in a non-intuitive way. Actually,
whatever the effect of the first and second events are, I would say
they both end at the same time. (Again, sustain pedal held.) I don't
think the loud note finishes any sooner than the soft note, does it?
In fact the soft note might actually finish sooner implying velocity
effects the overall length of the envelope.

   If the instrument being modeled is a synth, and assuming unlimited
oscillator count, then there are just two separate events that take
place in parallel.

   Probably this ramble isn't adding anything to the knowledge base
other than to say I'm out here reading.

Take care,
Mark

Re: [Linuxsampler-devel] cancel release on note on?

[Andreas P. <and...@lk...>]

Christian Schoenebeck wrote:
> But imagine the following case: you trigger key C3 the first time with a 
> velocity of 127, then you release key C3 and immediately after that press C3 
> again, but this time with a velocity of 1.
> 
> If we do what you claimed and remove those lines, you will hear nothing on the 
> 2nd key trigger. With current implementation though you still here the first 
> voice. Which makes sense, doesn't it?

Perhaps you're right. I wish I had a real piano nearby...

Anyway, I have now played a piano gig in LS with and without the cancel 
release in note on (that is, a practical test as opposed to the 
theoretical record-and-stare-at-zoomed-in-waveforms tests I did before), 
and: the difference is so subtle to me that my opinion on this almost 
faded away completely.

Just in case other type of instruments would behave differently, do you 
think it would be OK to insert "if (pInstrument->PianoReleaseMode)" 
around both cancel_release cases?

> I vote against that being the default behaviour. But of course if I'm alone 
> with that opinion I accepted it even as default behaviour.

My only argument for removing the lines per default would be that it 
makes the gig engine theoretically sound a little bit more like GS.

/Andreas

Re: [Linuxsampler-devel] cancel release on note on?

[Christian S. <sch...@so...>]

Es geschah am Sonntag 05 Dezember 2004 15:22 als Andreas Persson schrieb:
> Christian Schoenebeck wrote:
> > ProcessControlChange() only handles the sustain pedal case.
> > ProcessNoteOn() handles the case when the same key was triggered
> > instantly after releasing the same key. So this make sense.
>
> Sorry for being so stubborn, but I'm not sure I understand when the
> second case adds any realism?

There's nothing to excuse, doubts are often productive.

I guess you don't see a realism, because you assume the 2nd key trigger causes 
a new voice of approx. the same amplitude or even higher than the first one. 

But imagine the following case: you trigger key C3 the first time with a 
velocity of 127, then you release key C3 and immediately after that press C3 
again, but this time with a velocity of 1.

If we do what you claimed and remove those lines, you will hear nothing on the 
2nd key trigger. With current implementation though you still here the first 
voice. Which makes sense, doesn't it?

> > Again, we can make that a compile time option if you like.
>
> OK, but what will be the default? :)

I vote against that being the default behaviour. But of course if I'm alone 
with that opinion I accepted it even as default behaviour.

CU
Christian

Re: [Linuxsampler-devel] cancel release on note on?

[Andreas P. <and...@lk...>]

Christian Schoenebeck wrote:

> ProcessControlChange() only handles the sustain pedal case. ProcessNoteOn() 
> handles the case when the same key was triggered instantly after releasing 
> the same key. So this make sense.

Sorry for being so stubborn, but I'm not sure I understand when the 
second case adds any realism?

I have done measurements with GS 2.5, and if they are correct, the 
cancel_release is done in the sustain pedal case (if "Piano release 
mode" is on), but not in the retrigger case.

> Again, we can make that a compile time option if you like.

OK, but what will be the default? :)

/Andreas

Re: [Linuxsampler-devel] cancel release on note on?

[Christian S. <sch...@so...>]

Es geschah am Sonntag 05 Dezember 2004 14:00 als Andreas Persson schrieb:
> Christian Schoenebeck wrote:
> > Es geschah am Samstag 04 Dezember 2004 15:55 als Andreas Persson schrieb:
> >>If a key is pressed, released and then pressed again before the release
> >>of the first note has finished, the release of the first note is
> >>canceled - the first note continues to play until the second note is
> >>released. Why is that? Is it intentional? It doesn't seem like GS
> >>behaves like that.
> >
> > Yes, that's in fact intentional. Because it's a more natural behaviour.
> > If you release a key on a real piano and e.g. press the sustain pedal
> > immediately after that it would also first damp the wave but then when
> > the pedal is pressed would let the wave fade out slowly at the reached
> > amplitude level when the pedal was pressed.
>
> Yes, this is the "Piano release mode" in GS, and I agree it's a nice
> feature. But it is handled fine in Engine::ProcessControllChange. The
> code in ProcessNoteOn is not needed for this if I understand things
> correctly?

ProcessControlChange() only handles the sustain pedal case. ProcessNoteOn() 
handles the case when the same key was triggered instantly after releasing 
the same key. So this make sense.

> For me, the ProcessNoteOn code only seems to eat polyphony and make the
> second note unnecessarily loud.

Again, we can make that a compile time option if you like.

CU
Christian

Re: [Linuxsampler-devel] Bug report and possible bug fix for disk streaming

[Christian S. <sch...@so...>]

Es geschah am Sonntag 05 Dezember 2004 11:37 als Andreas Persson schrieb:
> Hello,
>
> I've found a bug in the streaming-from-disk code. I use a test gig with
> a short, mono, non-looped wave. The wave is 120976 samples long, and the
> problem is that not all of it are played when I press and hold a key.
> The disk thread reads the complete wave, but the audio thread does not
> render all samples - it seems as it stops after the cached 32768 samples.
>
> The attached patch (one line) seems to fix the problem - but, I
> definetly don't have a full understanding of the Stream class and the
> interaction between the threads, so it would be nice if someone that
> has, could look at it.


Index: linuxsampler/src/engines/gig/Stream.h
===================================================================
RCS file: /var/cvs/linuxsampler/linuxsampler/src/engines/gig/Stream.h,v
retrieving revision 1.2
diff -u -2 -r1.2 Stream.h
--- linuxsampler/src/engines/gig/Stream.h 27 Apr 2004 09:21:58 -0000 1.2
+++ linuxsampler/src/engines/gig/Stream.h 5 Dec 2004 10:28:18 -0000
@@ -59,5 +59,5 @@
 
             inline int GetReadSpace() {
-                return (pRingBuffer && State == state_active) ? 
pRingBuffer->read_space()  : 0;
+                return (pRingBuffer && State != state_unused) ? 
pRingBuffer->read_space()  : 0;
             }

Ouch, yes, that's definitely a bug. We must have forgotten that when the 
meaning of the stream states changed. This bug caused that already read data 
of the end of samples were overwritten by silence. The code to write the 
silence at the end (in Voice.cpp) should also be modified so that only as 
much silence is written as necessary. I will fix that.

Thanks for the report!

CU
Christian

Re: [Linuxsampler-devel] cancel release on note on?

[Andreas P. <and...@lk...>]

Christian Schoenebeck wrote:
> Es geschah am Samstag 04 Dezember 2004 15:55 als Andreas Persson schrieb:

>>If a key is pressed, released and then pressed again before the release
>>of the first note has finished, the release of the first note is
>>canceled - the first note continues to play until the second note is
>>released. Why is that? Is it intentional? It doesn't seem like GS
>>behaves like that.
> 
> 
> Yes, that's in fact intentional. Because it's a more natural behaviour. If you 
> release a key on a real piano and e.g. press the sustain pedal immediately 
> after that it would also first damp the wave but then when the pedal is 
> pressed would let the wave fade out slowly at the reached amplitude level 
> when the pedal was pressed.

Yes, this is the "Piano release mode" in GS, and I agree it's a nice 
feature. But it is handled fine in Engine::ProcessControllChange. The 
code in ProcessNoteOn is not needed for this if I understand things 
correctly?

For me, the ProcessNoteOn code only seems to eat polyphony and make the 
second note unnecessarily loud.

/Andreas

Re: [Linuxsampler-devel] cancel release on note on?

[Christian S. <sch...@so...>]

Es geschah am Samstag 04 Dezember 2004 15:55 als Andreas Persson schrieb:
> Hello,

Hi and sorry for the late response.

> If a key is pressed, released and then pressed again before the release
> of the first note has finished, the release of the first note is
> canceled - the first note continues to play until the second note is
> released. Why is that? Is it intentional? It doesn't seem like GS
> behaves like that.

Yes, that's in fact intentional. Because it's a more natural behaviour. If you 
release a key on a real piano and e.g. press the sustain pedal immediately 
after that it would also first damp the wave but then when the pedal is 
pressed would let the wave fade out slowly at the reached amplitude level 
when the pedal was pressed.

So I don't agree to remove that, but we can of course make that a compile time 
option if you like.

CU
Christian

Re: [Linuxsampler-devel] Bug report and possible bug fix for disk streaming

[Robert J. <rj...@sp...>]

Ah, great!

I reported an issue about clicking at the end of samples a few months back=
=20
(sadly I never got around to sending examples here), this sounds like it=20
could be the same. Looking forward to test it, though that will be a while=
=20
again...

/Robert


s=F6ndagen den 5 december 2004 11.37 skrev Andreas Persson:
> Hello,
>
> I've found a bug in the streaming-from-disk code. I use a test gig with
> a short, mono, non-looped wave. The wave is 120976 samples long, and the
> problem is that not all of it are played when I press and hold a key.
> The disk thread reads the complete wave, but the audio thread does not
> render all samples - it seems as it stops after the cached 32768 samples.
>
> The attached patch (one line) seems to fix the problem - but, I
> definetly don't have a full understanding of the Stream class and the
> interaction between the threads, so it would be nice if someone that
> has, could look at it.
>
> /Andreas

=2D-=20
http://spamatica.se/music/

[Linuxsampler-devel] Bug report and possible bug fix for disk streaming

[Andreas P. <and...@lk...>]

Hello,

I've found a bug in the streaming-from-disk code. I use a test gig with 
a short, mono, non-looped wave. The wave is 120976 samples long, and the 
problem is that not all of it are played when I press and hold a key. 
The disk thread reads the complete wave, but the audio thread does not 
render all samples - it seems as it stops after the cached 32768 samples.

The attached patch (one line) seems to fix the problem - but, I 
definetly don't have a full understanding of the Stream class and the 
interaction between the threads, so it would be nice if someone that 
has, could look at it.

/Andreas

[Linuxsampler-devel] cancel release on note on?

[Andreas P. <and...@lk...>]

Hello,

If a key is pressed, released and then pressed again before the release 
of the first note has finished, the release of the first note is 
canceled - the first note continues to play until the second note is 
released. Why is that? Is it intentional? It doesn't seem like GS 
behaves like that.

As the fix for this is to simply remove some code, I have a feeling I'm 
missing something. These lines from Engine::ProcessNoteOn are the ones I 
would like to remove:

         // cancel release process of voices on this key if needed
         if (pKey->Active && !SustainPedal) {
             RTList<Event>::Iterator itCancelReleaseEvent = 
pKey->pEvents->allocAppend();
             if (itCancelReleaseEvent) {
                 *itCancelReleaseEvent = *itNoteOnEvent; 
   // copy event
                 itCancelReleaseEvent->Type = 
Event::type_cancel_release; // transform event type
             }
             else dmsg(1,("Event pool emtpy!\n"));
         }

/Andreas

Re: [Linuxsampler-devel] gig3 experiment

[Christian S. <sch...@so...>]

Es geschah am Samstag 27 November 2004 12:58 als Andreas Persson schrieb:
> I ignored all new (and for me unknown) features and made some small
> changes to libgig, and - it worked! The offsets in the sample pool table
> are now 64 bits, supporting large files. I cheated and removed the upper
> half of the offsets. The samples are 24 bits. I cheated and removed the
> lower 8 bits. Looped or compressed samples are not supported, and
> probably a million other things, but I do have gig3 pipe organ sounds
> coming out of LS!

Very, very fine! :)

We now just have to clean up those changes a little bit. E.g.:

Index: linuxsampler/src/lib/fileloader/libgig/DLS.cpp
===================================================================
RCS 
file: /var/cvs/linuxsampler/linuxsampler/src/lib/fileloader/libgig/DLS.cpp,v
retrieving revision 1.2
diff -u -2 -r1.2 DLS.cpp
--- linuxsampler/src/lib/fileloader/libgig/DLS.cpp 27 Apr 2004 09:21:58 -0000 
1.2
+++ linuxsampler/src/lib/fileloader/libgig/DLS.cpp 27 Nov 2004 11:21:17 -0000
@@ -415,5 +415,13 @@
         pWavePoolTable = new uint32_t[WavePoolCount];
         ptbl->SetPos(headersize);
-        ptbl->Read(pWavePoolTable, WavePoolCount, sizeof(uint32_t));
+
+        // Check for 64 bit offsets (used in gig v3 files)
+        if (ptbl->GetSize() - headersize == WavePoolCount * 8) {
+            for (int i = 0 ; i < WavePoolCount ; i++) {
+                ptbl->ReadUint32(); // Just ignore the upper bits for now
+                pWavePoolTable[i] = ptbl->ReadUint32();
+            }
+        } else
+            ptbl->Read(pWavePoolTable, WavePoolCount, sizeof(uint32_t));

this should better check for the file format version instead of testing the 
size of the pool table chunk. Otherwise we'll get into trouble with even 
newer format versions.

and next:

Index: linuxsampler/src/lib/fileloader/libgig/gig.cpp
===================================================================
RCS 
file: /var/cvs/linuxsampler/linuxsampler/src/lib/fileloader/libgig/gig.cpp,v
retrieving revision 1.7
diff -u -2 -r1.7 gig.cpp
--- linuxsampler/src/lib/fileloader/libgig/gig.cpp 21 Nov 2004 18:07:42 -0000 
1.7
+++ linuxsampler/src/lib/fileloader/libgig/gig.cpp 27 Nov 2004 11:21:18 -0000
@@ -67,8 +67,8 @@
         if (Compressed) {
             ScanCompressedSample();
-            if (!pDecompressionBuffer) {
-                pDecompressionBuffer    = new 
int8_t[INITIAL_SAMPLE_BUFFER_SIZE];
-                DecompressionBufferSize = INITIAL_SAMPLE_BUFFER_SIZE;
-            }
+        }
+        if (!pDecompressionBuffer) {
+            pDecompressionBuffer    = new int8_t[INITIAL_SAMPLE_BUFFER_SIZE];
+            DecompressionBufferSize = INITIAL_SAMPLE_BUFFER_SIZE;
         }
  FrameOffset = 0; // just for streaming compressed samples

the decompresstion buffer should really only be allocated in case of 
compressed samples or on v3 file format gigs.

The sample Read() code vor v3 should be improved of course, but that's ok for 
the moment.

Anyway, great work !

CU
Christian

[Linuxsampler-devel] libgig 1.0.0

[Christian S. <sch...@so...>]

Hi!

seems Rui's mail once again escaped to nirvana. Maybe it will make it's way 
back to this list after a short holiday. ;)

The latest release 1.0.0 of libgig (sources, docs, Debian packages and thanks 
to Rui also Mandrake, Fedora and SuSE packages) can be found on the libgig 
website:

 http://stud.fh-heilbronn.de/~cschoene/projects/libgig

As always, sources and RPMs are also available on Rui's personal page

   http://www.rncbc.org/ls

and on the Qsampler sourceforge.net project page:

   http://sourceforge.net/projects/qsampler

CU
Christian

[Linuxsampler-devel] gig3 experiment

[Andreas P. <and...@lk...>]

Hello!

Don't know if anyone else already did this, but anyway...

I don't have GigaStudio 3, I have never tried it. But, I still got 
curious when I found some (huge) demo gig files for GS3 at:

http://www.ndb.hu/

How different would the file format be, and how hard would it be to make 
LinuxSampler to play the files? It turned out that the file format looks 
very similar. Some of the chunks have grown and there are a few new 
chunk types, but the overall structure is the same.

I ignored all new (and for me unknown) features and made some small 
changes to libgig, and - it worked! The offsets in the sample pool table 
are now 64 bits, supporting large files. I cheated and removed the upper 
half of the offsets. The samples are 24 bits. I cheated and removed the 
lower 8 bits. Looped or compressed samples are not supported, and 
probably a million other things, but I do have gig3 pipe organ sounds 
coming out of LS!

/Andreas

[Linuxsampler-devel] libgig 1.0.0 packages

[Rui N. C. <rn...@rn...>]

Hi,

Heads up. This is about to note that I have those libgig 1.0.0 packages
ready and available from the following urls:

My personal homeserver:
    http://www.rncbc.org/ls/

Qsampler sourceforge.net project page:
    http://sourceforge.net/projects/qsampler

I've made a standard release source tarball, libgig-1.0.0.tar.gz (packaged
via 'make dist') and a gang of RPMs for SUSE 9.2, Mandrake 10.1 and Fedora
core 1. RPMs are x86 only.

Enjoy,
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

[Linuxsampler-devel] gig3 experiment

[Andreas P. <and...@sp...>]

Hello!

Don't know if anyone else already did this, but anyway...

I don't have GigaStudio 3, I have never tried it. But, I still got 
curious when I found some (huge) demo gig files for GS3 at:

http://www.ndb.hu/

How different would the file format be, and how hard would it be to make 
LinuxSampler to play the files? It turned out that the file format looks 
very similar. Some of the chunks have grown and there are a few new 
chunk types, but the overall structure is the same.

I ignored all new (and for me unknown) features and made some small 
changes to libgig, and - it worked! The offsets in the sample pool table 
are now 64 bits, supporting large files. I cheated and removed the upper 
half of the offsets. The samples are 24 bits. I cheated and removed the 
lower 8 bits. Looped or compressed samples are not supported, and 
probably a million other things, but I do have gig3 pipe organ sounds 
coming out of LS!

/Andreas

Re: [Linuxsampler-devel] [PATCH] libgig version 0.7.2

[Christian S. <sch...@so...>]

Es geschah am Donnerstag 25 November 2004 13:52 als Rui Nuno Capela schrieb:
> On all of the autotools installations I have around (Mdk 10.1, SUSE 9.2
> and FC1) the man pages weren't being installed at all.
>
> As it seemed, if man_MANS is not set, automake just don't generate any
> actual make install rules. Go figure, it's the same autocrapola as usual
> ;)

Strange, it worked fine on Debian Woody, Sarge and Sid.

> Not higly urgent, but by bumping up the version number I can get better
> track of my own RPM packaging. Notice that the oneliner gig.h change is an
> issue as for building qsampler from source, so youl better be sure you
> have libgig-devel-0.7.2 installed and not libgig-devel-0.7.1.

Well, if qsampler doesn't build that's really an issue. Then I propose you 
commit your patch, leaving the version untouched and I promise I will do the 
Debian specific changes tomorrow, so we can fire out the 1.0.0 release 
tomorrow. It wouldn't make sense to make two releasese in few days, just 
because of my tiny Debian packaging changes.

CU
Christian

Re: [Linuxsampler-devel] [PATCH] libgig version 0.7.2

[Rui N. C. <rn...@rn...>]

Hi Christian,

>> This all comes to the attached patch, which also applies for correcting
>> some other minor documentation install problems (man pages and doxygen
>> docs).
>
> I wanted to fix the doxygen issue a while ago, thanks! But what's the
> reason for this man change?
>
> diff -duPNr libgig-0.7.1-0/man/Makefile.am libgig-0.7.2-0/man/Makefile.am
> --- libgig-0.7.1-0/man/Makefile.am 2004-07-07 13:03:54.000000000 +0100
> +++ libgig-0.7.2-0/man/Makefile.am 2004-11-24 12:57:40.431283288 +0000
> @@ -1,7 +1,7 @@
>  ## Process this file with automake to produce Makefile.in
>
>  # all man files that should be installed
> -man1_MANS = dlsdump.1 gigdump.1 gigextract.1 rifftree.1
> +man_MANS = dlsdump.1 gigdump.1 gigextract.1 rifftree.1
>

On all of the autotools installations I have around (Mdk 10.1, SUSE 9.2
and FC1) the man pages weren't being installed at all.

As it seemed, if man_MANS is not set, automake just don't generate any
actual make install rules. Go figure, it's the same autocrapola as usual
;)


>> If nothing or no one goes against this, I'll be ready to commit into CVS
>> soon.
>>
>> Oh, this patch also applies for bumping up the libgig package version to
>> 0.7.2. Please check it out carefully, and tell me if you agree.
>
> How urgent is this? My plan was to package the next release of libgig
> parallel to the release of LS and bumb the version to 1.0.0 to continue
> with libtool versioning scheme from that on. So can this wait for one or
> two weeks? If yes please just commit the changes and leave the version
> unchanged so far. I also have to change some tiny things in Debian
> packaging.
>

Not higly urgent, but by bumping up the version number I can get better
track of my own RPM packaging. Notice that the oneliner gig.h change is an
issue as for building qsampler from source, so youl better be sure you
have libgig-devel-0.7.2 installed and not libgig-devel-0.7.1.

I shall not touch the libtool versioning (0:0:0), so I think my proposed
version bump is just an interim and janitoral tagging measure.

I can see no harm in it, but you're the boss :)
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] [PATCH] libgig version 0.7.2

[Christian S. <sch...@so...>]

Es geschah am Donnerstag 25 November 2004 11:59 als Rui Nuno Capela schrieb:
> This all comes to the attached patch, which also applies for correcting
> some other minor documentation install problems (man pages and doxygen
> docs).

I wanted to fix the doxygen issue a while ago, thanks! But what's the reason 
for this man change?

diff -duPNr libgig-0.7.1-0/man/Makefile.am libgig-0.7.2-0/man/Makefile.am
--- libgig-0.7.1-0/man/Makefile.am 2004-07-07 13:03:54.000000000 +0100
+++ libgig-0.7.2-0/man/Makefile.am 2004-11-24 12:57:40.431283288 +0000
@@ -1,7 +1,7 @@
 ## Process this file with automake to produce Makefile.in
 
 # all man files that should be installed
-man1_MANS = dlsdump.1 gigdump.1 gigextract.1 rifftree.1
+man_MANS = dlsdump.1 gigdump.1 gigextract.1 rifftree.1

> If nothing or no one goes against this, I'll be ready to commit into CVS
> soon.
>
> Oh, this patch also applies for bumping up the libgig package version to
> 0.7.2. Please check it out carefully, and tell me if you agree.

How urgent is this? My plan was to package the next release of libgig parallel 
to the release of LS and bumb the version to 1.0.0 to continue with libtool 
versioning scheme from that on. So can this wait for one or two weeks? If yes 
please just commit the changes and leave the version unchanged so far. I also 
have to change some tiny things in Debian packaging.

CU
Christian

[Linuxsampler-devel] [PATCH] libgig version 0.7.2

[Rui N. C. <rn...@rn...>]

Hi Chris, everyone,

(I'm re-posting this as I didn't got anything back from linuxsampler-devel
list to date; just lag or has it gone the drain of some spam blackhole?
sorry for th einconvenience)


While integrating libgig support into QSampler I've detected a minor quirk
in the "gig.h" header file, that has been solved by simply inserting a
oneliner: a forward declaration of gig::Region class.

Apparentely, a compiler error was just exposed if you include "gig.h"
under a Qt C++ project (as is qsampler), and was all about "Region" being
an already typedef'd symbol.

This all comes to the attached patch, which also applies for correcting
some other minor documentation install problems (man pages and doxygen
docs).

If nothing or no one goes against this, I'll be ready to commit into CVS
soon.

Oh, this patch also applies for bumping up the libgig package version to
0.7.2. Please check it out carefully, and tell me if you agree.

Hope so.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...