timidity-devel — Timidity Development mailing list

Re: [Timidity-devel] timidity: --segment (multi segments, RC_CUEPOINT)

[TAMUKI S. <ta...@li...>]

Hello Yotam,

I apologize for the delay in replying.

From: Yotam Medini <yot...@gm...>
Subject: Re: [Timidity-devel] timidity: --segment (multi segments, RC_CUEPOINT)
Date: Tue, 7 Apr 2015 01:12:16 +0300

> > > 2. Each the begin-end range with a dash ('-').
> > >    This practically prevents using negative time=points.
> > >    these are probably not needed. Right?
> >
> > Yes, negative time points may be not needed.  In the future, the
> > setting of each start-end point hopes to be designated not only by
> > "minute:second" but also by "measure.beat".
> 
> The additional "measure:beat" segment interface is nice.
> See more comments below.

Thank you for your compliments.

> > > 3. Your suggestion to use RC_CUEPOINT & RC_NEXT
> > >    rather than directly changing midi_restart_time seems cleaner.
> > >    Would you suggest having these events:
> > >      (a) come from:
> > >             rc = ctl->read(&val)   @ playmidi.c:apply_controls()
> > >          Currently, I do not see a clean way to generate them
> > >          from segments-data  into the virtual (ControlMode *ctl) mechanism.
> >
> > Sorry, using RC_CUEPOINT is aimed at interactive settings during
> > playing in some interfaces on the fly.  So, currently not needed.
> 
> A few months ago, you have suggested this RC_CUEPOINT,
> along with pseudo example. See more comments below.

Yes, of course RC_CUEPOINT is needed when using interactive settings
during playing in some interfaces on the fly.  For example, on ncurses
interface, users can hit some keys at points desired to start and end
of segments repeatedly, and then restart (or wait until the next loop
of) the song.  But the requirement for now is to specify the segments
via command line option.

> > First, each cue point will be added to a midi event list as a midi
> > event (ME_CUEPOINT) by readmidi_add_event().  In seek_forward() and
> > play_event(), if the event type matches ME_CUEPOINT, it will perform
> > a processing required for the segment play.
> 
> Forcing cue-points to become midi-events sounds somewhat artificial.

Well, I think that is not a bad idea to implement the action depending
upon the running time.  However, ME_CUEPOINT should not be added to
the "real" midi event list.  It should be added to another event list
that stores progress-control events by TiMidity++, because the events
might be modified or removed via some interfaces on the fly.

> > For example:
> > 
> >         case ME_CUEPOINT:
> >                 i = ev->a + ((ev->b & 0x0f) << 8);      <-- meas (12 bits)
> >                 j = ev->b >> 4;                         <-- beat (4 bits)
> > 
> > where a pair of meas/beat stands for a relative range to skip
> > playing, if they are 0xffff, it will skip to the end.
> 
> Having a measure (bar) limit of 4096=2^{12} is fine,
> but I could expect cases where one would wish to point to a beat > 16.

Yes, you are right.  According to Standard MIDI-File Format Spec. 1.1,
the numerator of the time signature is expressed up to 255, so a beat
should have 8 bits.  However, TiMidity++ can display meas/beat on some
interfaces in the range of 12 bits / 4 bits respectively for now. :-(
Well, it does not become any problem when ordinarily used.

> I support the spirit in your saying:
>    'In the _future_ ... _not_only_ by "minute:second" ...'
> Segment end-points defined via 'bar:beat' is nice, but in general
> the 'minute:second' is more useful for the following reasons:
> 1. People lacking music notation education
>    may have no clue what measure and beat exactly mean.
>    While 'human' time notation is more obvious.

I think so, too.  I intend to remain "minute:second" notation in the
command line option.

> 2. Frequently midi files do not contain introductory measures,
>    which makes measure-numbering inconsistent between the
>    'official' music score and the midi-file.

TiMidity++ can display the measure-numbering in the midi-file on some
interfaces, so no problem.

> 3. In modern compositions, measure lengths vary, which may add
>    to confusion.
>    In pre-baroque music, bars frequently do not exist.

Hmm, that's interesting.

> 4. Timidity already nicely reports running time via mm:ss.

Some major interfaces in TiMidity++ such as ncurses, XAW, and Windows
GUI already nicely report running time via meas.beat notation.  Also,
dumb interface probably should report running time via meas.beat.

> 5. Populat command line tools, such as 'mplayer' and 'mp3splt'
>    use time-notation to play or extract music segments.
> 
> Therefore, let us concentrate on a well-working
> '--segment' feature via 'minute:second' released,
> and consider 'measure:beat' a future feature enhancement.

As mentioned above, I intend to remain "minute:second" notation in the
command line option.  I still think that "measure:beat" notation is
more convenient.  Anyway, that is little importance because of the
command line option.

> Considering the 'minute:seconds.milliseconds' data -
> If we want to insert it into 16=8+8 bits of a midi-event
> and still support large midi files (> 40 minutes)
> [For example: http://gustavmahler.com/midi.html Symphony2/movement5]
> our units must be larger that 1/3 of a second.
> Possible, but losing desired accuracy.

Let's decide the internal representation of the time-points as the sum
of Delta-times (i.e. TiMidity++ is used in smf_at_time.)  According to
Standard MIDI-File Format Spec. 1.1, Delta-time is in some fraction of
a beat (or second, for recording a track with SMPTE times.)

> Segments or Cue-points - in my opinion - are closer to a user
> control-events than to a pure midi-event derived from a midi-file.
> As you once suggested (2014/November/2)
> -> In other words, the segment play can be regarded as one of control
> -> operation of repeated key striking of "f" to reach start of MIDI and
> -> striking of "n" to finish the playing gracefully.
> Thus - I suggest we stick to the idea of introducing and using
> RC_CUEPOINT code with (int32 val).

I have certainly suggested above, but I think it will be difficult to
indicate the invoking timing of RC_CUEPOINT.  By the way, TiMidity++
already has some functions that control channel mute and/or key change
at desired timing via command line -Qn[,...]t and/or -Hn option.

Regards,
TAMUKI Shoichi

Re: [Timidity-devel] timidity: --segment (multi segments, RC_CUEPOINT)

[Yotam M. <yot...@gm...>]

Hello Tamuki,

Could you please reply to my April-7th note.
I wish to go ahead with my suggested plan, but I need your approval.

While at it, are there any other active Timidity++ developers?

Have a nice weekend -- yotam

On Tue, 7 Apr 2015 01:12:16 +0300
Yotam Medini <yot...@gm...> wrote:

> Hello Tamuki,
> 
> Thank you for your feedback and suggestions.
> 
> > > ...
> > ...
> > > 2. Each the begin-end range with a dash ('-').
> > >    This practically prevents using negative time=points.
> > >    these are probably not needed. Right?
> >
> > Yes, negative time points may be not needed.  In the future, the
> > setting of each start-end point hopes to be designated not only by
> > "minute:second" but also by "measure.beat".
> 
> The additional "measure:beat" segment interface is nice.
> See more comments below.
> 
> > > 3. Your suggestion to use RC_CUEPOINT & RC_NEXT
> > >    rather than directly changing midi_restart_time seems cleaner.
> > >    Would you suggest having these events:
> > >      (a) come from:
> > >             rc = ctl->read(&val)   @ playmidi.c:apply_controls()
> > >          Currently, I do not see a clean way to generate them
> > >          from segments-data  into the virtual (ControlMode *ctl) mechanism.
> >
> > Sorry, using RC_CUEPOINT is aimed at interactive settings during
> > playing in some interfaces on the fly.  So, currently not needed.
> 
> A few months ago, you have suggested this RC_CUEPOINT,
> along with pseudo example. See more comments below.
> 
> > >    or:
> > >      (b) resulted by changing
> > >            switch(rc = ctl->read(&val))   @ playmidi.c:apply_controls()
> > >            ...
> > >          into (pseudo-code):
> > >            rc = ctl->read(&val);
> > >            if (rc == RC_NONE) and segments) {
> > >               if (not yet CUE-ed in this play)
> > >                  rc = RC_CUEPOINT;  val = first_segment.begin;
> > >               else if (current_trace_samples() outside current segment) {
> > >                  if (next_segment) {
> > >                     rc = RC_CUEPOINT;  val = next_segment.begin
> > >                  } else {
> > >                     rc = RC_NEXT;  no_yet_cued := TRUE;
> > >                  }
> > >               }
> > >            }
> > >            switch (rc)
> > >            ...
> > >       ??
> 
> > First, each cue point will be added to a midi event list as a midi
> > event (ME_CUEPOINT) by readmidi_add_event().  In seek_forward() and
> > play_event(), if the event type matches ME_CUEPOINT, it will perform
> > a processing required for the segment play.
> 
> Forcing cue-points to become midi-events sounds somewhat artificial.
> 
> > For example:
> >
> >         case ME_CUEPOINT:
> >                 i = ev->a + ((ev->b & 0x0f) << 8);      <-- meas (12 bits)
> >                 j = ev->b >> 4;                         <-- beat (4 bits)
> >
> > where a pair of meas/beat stands for a relative range to skip
> > playing, if they are 0xffff, it will skip to the end.
> 
> Having a measure (bar) limit of 4096=2^{12} is fine,
> but I could expect cases where one would wish to point to a beat > 16.
> 
> - - -
> 
> I support the spirit in your saying:
>    'In the _future_ ... _not_only_ by "minute:second" ...'
> Segment end-points defined via 'bar:beat' is nice, but in general
> the 'minute:second' is more useful for the following reasons:
> 1. People lacking music notation education
>    may have no clue what measure and beat exactly mean.
>    While 'human' time notation is more obvious.
> 2. Frequently midi files do not contain introductory measures,
>    which makes measure-numbering inconsistent between the
>    'official' music score and the midi-file.
> 3. In modern compositions, measure lengths vary, which may add
>    to confusion.
>    In pre-baroque music, bars frequently do not exist.
> 4. Timidity already nicely reports running time via mm:ss.
> 5. Populat command line tools, such as 'mplayer' and 'mp3splt'
>    use time-notation to play or extract music segments.
> 
> Therefore, let us concentrate on a well-working
> '--segment' feature via 'minute:second' released,
> and consider 'measure:beat' a future feature enhancement.
> 
> Considering the 'minute:seconds.milliseconds' data -
> If we want to insert it into 16=8+8 bits of a midi-event
> and still support large midi files (> 40 minutes)
> [For example: http://gustavmahler.com/midi.html Symphony2/movement5]
> our units must be larger that 1/3 of a second.
> Possible, but losing desired accuracy.
> 
> Segments or Cue-points - in my opinion - are closer to a user
> control-events than to a pure midi-event derived from a midi-file.
> As you once suggested (2014/November/2)
> -> In other words, the segment play can be regarded as one of control
> -> operation of repeated key striking of "f" to reach start of MIDI and
> -> striking of "n" to finish the playing gracefully.
> Thus - I suggest we stick to the idea of introducing and using
> RC_CUEPOINT code with (int32 val).
> 
> regards -- yotam

Re: [Timidity-devel] timidity: --segment (multi segments, RC_CUEPOINT)

[Yotam M. <yot...@gm...>]

Hello Tamuki,

Thank you for your feedback and suggestions.

> > ...
> ...
> > 2. Each the begin-end range with a dash ('-').
> >    This practically prevents using negative time=points.
> >    these are probably not needed. Right?
>
> Yes, negative time points may be not needed.  In the future, the
> setting of each start-end point hopes to be designated not only by
> "minute:second" but also by "measure.beat".

The additional "measure:beat" segment interface is nice.
See more comments below.

> > 3. Your suggestion to use RC_CUEPOINT & RC_NEXT
> >    rather than directly changing midi_restart_time seems cleaner.
> >    Would you suggest having these events:
> >      (a) come from:
> >             rc = ctl->read(&val)   @ playmidi.c:apply_controls()
> >          Currently, I do not see a clean way to generate them
> >          from segments-data  into the virtual (ControlMode *ctl) mechanism.
>
> Sorry, using RC_CUEPOINT is aimed at interactive settings during
> playing in some interfaces on the fly.  So, currently not needed.

A few months ago, you have suggested this RC_CUEPOINT,
along with pseudo example. See more comments below.

> >    or:
> >      (b) resulted by changing
> >            switch(rc = ctl->read(&val))   @ playmidi.c:apply_controls()
> >            ...
> >          into (pseudo-code):
> >            rc = ctl->read(&val);
> >            if (rc == RC_NONE) and segments) {
> >               if (not yet CUE-ed in this play)
> >                  rc = RC_CUEPOINT;  val = first_segment.begin;
> >               else if (current_trace_samples() outside current segment) {
> >                  if (next_segment) {
> >                     rc = RC_CUEPOINT;  val = next_segment.begin
> >                  } else {
> >                     rc = RC_NEXT;  no_yet_cued := TRUE;
> >                  }
> >               }
> >            }
> >            switch (rc)
> >            ...
> >       ??

> First, each cue point will be added to a midi event list as a midi
> event (ME_CUEPOINT) by readmidi_add_event().  In seek_forward() and
> play_event(), if the event type matches ME_CUEPOINT, it will perform
> a processing required for the segment play.

Forcing cue-points to become midi-events sounds somewhat artificial.

> For example:
>
>         case ME_CUEPOINT:
>                 i = ev->a + ((ev->b & 0x0f) << 8);      <-- meas (12 bits)
>                 j = ev->b >> 4;                         <-- beat (4 bits)
>
> where a pair of meas/beat stands for a relative range to skip
> playing, if they are 0xffff, it will skip to the end.

Having a measure (bar) limit of 4096=2^{12} is fine,
but I could expect cases where one would wish to point to a beat > 16.

- - -

I support the spirit in your saying:
   'In the _future_ ... _not_only_ by "minute:second" ...'
Segment end-points defined via 'bar:beat' is nice, but in general
the 'minute:second' is more useful for the following reasons:
1. People lacking music notation education
   may have no clue what measure and beat exactly mean.
   While 'human' time notation is more obvious.
2. Frequently midi files do not contain introductory measures,
   which makes measure-numbering inconsistent between the
   'official' music score and the midi-file.
3. In modern compositions, measure lengths vary, which may add
   to confusion.
   In pre-baroque music, bars frequently do not exist.
4. Timidity already nicely reports running time via mm:ss.
5. Populat command line tools, such as 'mplayer' and 'mp3splt'
   use time-notation to play or extract music segments.

Therefore, let us concentrate on a well-working
'--segment' feature via 'minute:second' released,
and consider 'measure:beat' a future feature enhancement.

Considering the 'minute:seconds.milliseconds' data -
If we want to insert it into 16=8+8 bits of a midi-event
and still support large midi files (> 40 minutes)
[For example: http://gustavmahler.com/midi.html Symphony2/movement5]
our units must be larger that 1/3 of a second.
Possible, but losing desired accuracy.

Segments or Cue-points - in my opinion - are closer to a user
control-events than to a pure midi-event derived from a midi-file.
As you once suggested (2014/November/2)
-> In other words, the segment play can be regarded as one of control
-> operation of repeated key striking of "f" to reach start of MIDI and
-> striking of "n" to finish the playing gracefully.
Thus - I suggest we stick to the idea of introducing and using
RC_CUEPOINT code with (int32 val).

regards -- yotam

Re: [Timidity-devel] timidity: --segment (multi segments, RC_CUEPOINT)

[TAMUKI S. <ta...@li...>]

Hello Yotam,

From: Yotam Medini <yot...@gm...>
Subject: [Timidity-devel] timidity: --segment (multi segments, RC_CUEPOINT)
Date: Tue, 31 Mar 2015 21:20:37 +0300

> Sorry for being inactive for so long.
> Lots of choir rehearsals, performances in Israel & Germany,
> and moving day jobs (Cisco -> Kaminario) absorbed my free time.
> Let me say that my current modified version of 'timidity' was sufficient
> for helping me prepare for my choir.

I see you are doing very well in your lifework and business.

> Back to development. When you suggest in your example:
>   $ timidity -idt --segment=00:15-00:30,00:45-01:00 sample.mid
> You actually augment and change the syntax of the --segment option.
> 1. Having multi comma-separated time-segments rather than one. Right?

Yes, I think it should be better that having multi comma-separated
time-segments is included in the segment play function.  In the
future, the setting range hopes to be designated not only by command
line options but also by interactive settings during playing in some
interfaces on the fly.

> 2. Each the begin-end range with a dash ('-').
>    This practically prevents using negative tim=points.
>    these are probably not needed. Right?

Yes, negative time points may be not needed.  In the future, the
setting of each start-end point hopes to be designated not only by
"minute:second" but also by "measure.beat".

> 3. Your suggestion to use RC_CUEPOINT & RC_NEXT
>    rather than directly changing midi_restart_time seems cleaner.
>    Would you suggest having these events:
>      (a) come from:
>             rc = ctl->read(&val)   @ playmidi.c:apply_controls()
>          Currently, I do not see a clean way to generate them
>          from segments-data  into the virtual (ControlMode *ctl) mechanism.

Sorry, using RC_CUEPOINT is aimed at interactive settings during
playing in some interfaces on the fly.  So, currently not needed.

>    or:
>      (b) resulted by changing
>            switch(rc = ctl->read(&val))   @ playmidi.c:apply_controls()
>            ...
>          into (pseudo-code):
>            rc = ctl->read(&val);
>            if (rc == RC_NONE) and segments) {
>               if (not yet CUE-ed in this play)
>                  rc = RC_CUEPOINT;  val = first_segment.begin;
>               else if (current_trace_samples() outside current segment) {
>                  if (next_segment) {
>                     rc = RC_CUEPOINT;  val = next_segment.begin
>                  } else {
>                     rc = RC_NEXT;  no_yet_cued := TRUE;
>                  }
>               }
>            }
>            switch (rc)
>            ...
>       ??

First, each cue point will be added to a midi event list as a midi
event (ME_CUEPOINT) by readmidi_add_event().  In seek_forward() and
play_event(), if the event type matches ME_CUEPOINT, it will perform
a processing required for the segment play.

For example:

	case ME_CUEPOINT:
		i = ev->a + ((ev->b & 0x0f) << 8);	<-- meas (12 bits)
		j = ev->b >> 4;				<-- beat (4 bits)

where a pair of meas/beat stands for a relative range to skip
playing, if they are 0xffff, it will skip to the end.

Regards,
TAMUKI Shoichi

[Timidity-devel] timidity: --segment (multi segments, RC_CUEPOINT)

[Yotam M. <yot...@gm...>]

Hello Tamuki Shoichi,

Sorry for being inactive for so long.
Lots of choir rehearsals, performances in Israel & Germany,
and moving day jobs (Cisco -> Kaminario) absorbed my free time.
Let me say that my current modified version of 'timidity' was sufficient
for helping me prepare for my choir.

Back to development. When you suggest in your example:
  $ timidity -idt --segment=00:15-00:30,00:45-01:00 sample.mid
You actually augment and change the syntax of the --segment option.
1. Having multi comma-separated time-segments rather than one. Right?
2. Each the begin-end range with a dash ('-').
   This practically prevents using negative tim=points.
   these are probably not needed. Right?
3. Your suggestion to use RC_CUEPOINT & RC_NEXT
   rather than directly changing midi_restart_time seems cleaner.
   Would you suggest having these events:
     (a) come from:
            rc = ctl->read(&val)   @ playmidi.c:apply_controls()
         Currently, I do not see a clean way to generate them
         from segments-data  into the virtual (ControlMode *ctl) mechanism.
   or:
     (b) resulted by changing
           switch(rc = ctl->read(&val))   @ playmidi.c:apply_controls()
           ...
         into (pseudo-code):
           rc = ctl->read(&val);
           if (rc == RC_NONE) and segments) {
              if (not yet CUE-ed in this play)
                 rc = RC_CUEPOINT;  val = first_segment.begin;
              else if (current_trace_samples() outside current segment) {
                 if (next_segment) {
                    rc = RC_CUEPOINT;  val = next_segment.begin
                 } else {
                    rc = RC_NEXT;  no_yet_cued := TRUE;
                 }
              }
           }
           switch (rc)
           ...
      ??

regards -- yotam

> From: TAMUKI Shoichi <ta...@li...>
> To: tim...@li...
> Subject: Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line
> Date: Mon, 03 Nov 2014 11:40:27 +0900
>
> To generalize the naming, it would be better to rename RC_SEGSTART to
> RC_CUEPOINT.
>
> For example, it would be also available the following command-line
> option syntax:
>
> $ timidity -idt --segment=00:15-00:30,00:45-01:00 sample.mid
>
> In this case, it would be perform as below:
>
> at 00:00, invoke RC_CUEPOINT val=00:15
> at 00:30, invoke RC_CUEPOINT val=00:45
> at 01:00, invoke RC_NEXT

Sorry for being inactive for so long.
Lots of choir rehearsals, performances in Israel & Germany,
and moved day jobs (Cisco -> Kaminario).
Let me say that my current modified version of 'timidity' was sufficient
for helping me prepare for my choir.

Back to development. When you suggest in your example:
  $ timidity -idt --segment=00:15-00:30,00:45-01:00 sample.mid
You actually augment and change the syntax of the --segment option.
1. Having multi comma-separated time-segments rather than one. Right?
2. Each the begin-end range with a dash ('-').
   This practically prevent use of negative tim=points.
   that are probably not needed.
   Right?
3. You suggestion to use RC_CUEPOINT & RC_NEXT
   rather than directly changing midi_restart_time seems cleaner.
   Would you suggest having these events:
     (a) come from:
            rc = ctl->read(&val)   @ playmidi.c:apply_controls()
         Currently, I do not see a clean way to generate them
         from segments-data  into the virtual (ControlMode *ctl) mechanism.
   or:
     (b) resulted by changing
           switch(rc = ctl->read(&val))   @ playmidi.c:apply_controls()
           ...
         into (pseudo-code):
           rc = ctl->read(&val);
           if (rc == RC_NONE) and segments) {
              if (not yet CUE-ed in this play)
                 rc = RC_CUEPOINT;  val = first_segment.begin;
              else if (current_trace_samples() outside current segment) {
                 if (next_segment) {
                    rc = RC_CUEPOINT;  val = next_segment.begin
                 } else {
                    rc = RC_NEXT;  no_yet_cued := TRUE;
                 }
              }
           }
           switch (rc)
           ...

regards -- yotam

> From: TAMUKI Shoichi <ta...@li...>
> To: tim...@li...
> Subject: Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line
> Date: Mon, 03 Nov 2014 11:40:27 +0900
>
> To generalize the naming, it would be better to rename RC_SEGSTART to
> RC_CUEPOINT.
>
> For example, it would be also available the following command-line
> option syntax:
>
> $ timidity -idt --segment=00:15-00:30,00:45-01:00 sample.mid
>
> In this case, it would be perform as below:
>
> at 00:00, invoke RC_CUEPOINT val=00:15
> at 00:30, invoke RC_CUEPOINT val=00:45
> at 01:00, invoke RC_NEXT

[Timidity-devel] [patch] fix build and fix man page

[Stas S. <st...@li...>]

Hello, attached are the 2 simple patches.

automake refuses to work without ChangeLog, so
this patch makes autogen.sh to create one.

The second patch is the fixes to the man page.

Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line

[TAMUKI S. <ta...@li...>]

Hello,

From: TAMUKI Shoichi <ta...@li...>
Subject: Re: [Timidity-devel] Fwd: patch: segment play,	time-ticks skip+stop on command line
Date: Sun, 02 Nov 2014 20:35:16 +0900

> I think that the processing of RC_FORWARD and RC_SEGSTART will be
> similar.  In overview, while the processing of RC_FORWARD is to do
> skip_to(current_sample + incremental), the processing of RC_SEGSTART
> will be to do skip_to(jump_destination_sample).  It is also necessary
> to add "#define RC_SEGSTART 34" in timidity/controls.h.

To generalize the naming, it would be better to rename RC_SEGSTART to
RC_CUEPOINT.

For example, it would be also available the following command-line
option syntax:

$ timidity -idt --segment=00:15-00:30,00:45-01:00 sample.mid

In this case, it would be perform as below:

at 00:00, invoke RC_CUEPOINT val=00:15
at 00:30, invoke RC_CUEPOINT val=00:45
at 01:00, invoke RC_NEXT

Regards,
TAMUKI Shoichi

Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line

[TAMUKI S. <ta...@li...>]

Hello,

From: Yotam Medini <yot...@gm...>
Subject: Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line
Date: Sat, 1 Nov 2014 11:51:15 +0200

> > Perhaps, it would be better not to replace midi_restart_time with
> > tick_begin directly, but use the variant of RC_FORWORD (introducing
> > RC_SEGSTART may be a good idea) for tick_begin, and use RC_NEXT for
> > tick_end instead.
> > 
> > Can you try to do that?
> 
> This {midi_restart_time->RC_FORWORD/RC_SEGSTART/RC_NEXT} change idea,
> is not related to the 'multi-file playing' problem. Right ?

I think that your method (replacing midi_restart_time with tick_begin
directly) may bring the internal status out of synchronism because the
internal representation will be read ahead.  That may be apparent on
the multi-file playing in particular.

> Considerting my lack of knowledge of Timidity's whole design,
> I am currently not too comfortable introducing a new control code,
> such as RC_SEGSTART. How is it injected? How to validate its context, etc.
> Would you be able to help me here?

I think that the processing of RC_FORWARD and RC_SEGSTART will be
similar.  In overview, while the processing of RC_FORWARD is to do
skip_to(current_sample + incremental), the processing of RC_SEGSTART
will be to do skip_to(jump_destination_sample).  It is also necessary
to add "#define RC_SEGSTART 34" in timidity/controls.h.

In other words, the segment play can be regarded as one of control
operation of repeated key striking of "f" to reach start of MIDI and
striking of "n" to finish the playing gracefully.

It could also select the segment play on the fly during the ncurses
interface or something in the future. :-)

> Regarding the multi-file playing. Do you accept my 'solution'
> of ignoring '--segment' in this case?

Sorry, no.  I think it is undesirable to discriminate between the
single-file playing and the multi-file playing.

Regards,
TAMUKI Shoichi

Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line

[Yotam M. <yot...@gm...>]

On Fri, 31 Oct 2014 08:16:42 +0900
TAMUKI Shoichi <ta...@li...> wrote:

> Hello,
> 
> From: TAMUKI Shoichi <ta...@li...>
> Subject: Re: [Timidity-devel] Fwd: patch: segment play,
> time-ticks skip+stop on command line Date: Thu, 30 Oct 2014 18:45:16
> +0900
> 
> > > > I tried your patch.  When playing with ncurses interface or
> > > > something, enabling --segment option will result in an
> > > > incorrect display.
> > > > 
> > > > For example:
> > > > $ timidity -int --segment 0:25,1:21 06-purif.mid
> > > 
> > > Today is the first time I used and compiled with ncurses support.
> > > I believe the display (panning) is fixed in ...-v05.diff.
> > > Basically now events e with (e->time == 0) are 'played' on first
> > > play, and skip_to(tick_begin)
> > > is called _after_ playing these zero-timed events.
> > 
> > Thank you for the revised patch.
> > 
> > Of course, I believe this feature also works on any interfaces other
> > than ncurses interface. :-)
> > 
> > I tried your patch.  When playing multiple MIDI files with ncurses
> > interface or something, enabling --segment option still result in an
> > incorrect display.  For example, the title display will not be
> > synchronized. :-(
> > 
> > $ timidity -int --segment 0:15,0:30 midipack.tar.gz (a lot of MIDI
> > files inside)
> 
> Perhaps, it would be better not to replace midi_restart_time with
> tick_begin directly, but use the variant of RC_FORWORD (introducing
> RC_SEGSTART may be a good idea) for tick_begin, and use RC_NEXT for
> tick_end instead.
> 
> Can you try to do that?

This {midi_restart_time->RC_FORWORD/RC_SEGSTART/RC_NEXT} change idea,
is not related to the 'multi-file playing' problem. Right ?

Considerting my lack of knowledge of Timidity's whole design,
I am currently not too comfortable introducing a new control code,
such as RC_SEGSTART. How is it injected? How to validate its context, etc.
Would you be able to help me here?

Regarding the multi-file playing. Do you accept my 'solution'
of ignoring '--segment' in this case?

> Regards,
> TAMUKI Shoichi

regards -- yotam

Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line

[TAMUKI S. <ta...@li...>]

Hello,

From: TAMUKI Shoichi <ta...@li...>
Subject: Re: [Timidity-devel] Fwd: patch: segment play,	time-ticks skip+stop on command line
Date: Thu, 30 Oct 2014 18:45:16 +0900

> > > I tried your patch.  When playing with ncurses interface or something,
> > > enabling --segment option will result in an incorrect display.
> > > 
> > > For example:
> > > $ timidity -int --segment 0:25,1:21 06-purif.mid
> > 
> > Today is the first time I used and compiled with ncurses support.
> > I believe the display (panning) is fixed in ...-v05.diff.
> > Basically now events e with (e->time == 0) are 'played' on first play,
> > and skip_to(tick_begin)
> > is called _after_ playing these zero-timed events.
> 
> Thank you for the revised patch.
> 
> Of course, I believe this feature also works on any interfaces other
> than ncurses interface. :-)
> 
> I tried your patch.  When playing multiple MIDI files with ncurses
> interface or something, enabling --segment option still result in an
> incorrect display.  For example, the title display will not be
> synchronized. :-(
> 
> $ timidity -int --segment 0:15,0:30 midipack.tar.gz (a lot of MIDI files inside)

Perhaps, it would be better not to replace midi_restart_time with
tick_begin directly, but use the variant of RC_FORWORD (introducing
RC_SEGSTART may be a good idea) for tick_begin, and use RC_NEXT for
tick_end instead.

Can you try to do that?

Regards,
TAMUKI Shoichi

Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line

[Yotam M. י. מ. <yot...@gm...>]

On Thu, Oct 30, 2014 at 11:45 AM, TAMUKI Shoichi <ta...@li...> wrote:

> Hello,
>
> From: Yotam Medini <yot...@gm...>
> Subject: Re: [Timidity-devel] Fwd: patch: segment play, time-ticks
> skip+stop on command line
> Date: Fri, 24 Oct 2014 20:26:29 +0300
>
>
> I tried your patch.  When playing multiple MIDI files with ncurses
> interface or something, enabling --segment option still result in an
> incorrect display.  For example, the title display will not be
> synchronized. :-(
>
> $ timidity -int --segment 0:15,0:30 midipack.tar.gz (a lot of MIDI files
> inside)
>
> Regards,
> TAMUKI Shoichi
>

Hello TAMUKI Shoichi,

Replying away from my home developing box.

The --segment feature is useful for a specific single midi-file.
How about ignoring the --segment option when more that 1 midi-file is given?

Please let me know if you approve this solution.
If so, I will also update the documentation and add a warning
when '--segment' is ignored.

regards -- yotam

Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line

[TAMUKI S. <ta...@li...>]

Hello,

From: Yotam Medini <yot...@gm...>
Subject: Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line
Date: Fri, 24 Oct 2014 20:26:29 +0300

> > I tried your patch.  When playing with ncurses interface or something,
> > enabling --segment option will result in an incorrect display.
> > 
> > For example:
> > $ timidity -int --segment 0:25,1:21 06-purif.mid
> 
> Today is the first time I used and compiled with ncurses support.
> I believe the display (panning) is fixed in ...-v05.diff.
> Basically now events e with (e->time == 0) are 'played' on first play,
> and skip_to(tick_begin)
> is called _after_ playing these zero-timed events.

Thank you for the revised patch.

Of course, I believe this feature also works on any interfaces other
than ncurses interface. :-)

I tried your patch.  When playing multiple MIDI files with ncurses
interface or something, enabling --segment option still result in an
incorrect display.  For example, the title display will not be
synchronized. :-(

$ timidity -int --segment 0:15,0:30 midipack.tar.gz (a lot of MIDI files inside)

Regards,
TAMUKI Shoichi

Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line

[Yotam M. <yot...@gm...>]

Hello Tamuki Shoichi,

Soon I will send you a new patch timidity-segment-v05.diff

> I see, that makes sense.  I hope you to use standard e-mail tools in
> the future, so that we may comment on specific portions of your code.
From the mail-header you may see that I now use claws-mail.
(A little headache, Reducing GMail security [OAuth2 issue?])


> Ok, but I would like you to submit patches with the latest source
> tree.  Would you please use TiMidity++-2.14.0-140821-1200.tar.bz2
> which is up to date, instead of TiMidity++-2.14.0.tar.bz2.

Your wish is my command. From now on, my pacthes will be based on it.

> > diff --git a/doc/C/timidity.1 b/doc/C/timidity.1
> > -.sp
> > +.s
> Perhaps, did you make a mistake there? (^_^;)

You're right, sorry. It is fixed in ...-v05.diff.

> I tried your patch.  When playing with ncurses interface or something,
> enabling --segment option will result in an incorrect display.
> 
> For example:
> $ timidity -int --segment 0:25,1:21 06-purif.mid

Today is the first time I used and compiled with ncurses support.
I believe the display (panning) is fixed in ...-v05.diff.
Basically now events e with (e->time == 0) are 'played' on first play,
and skip_to(tick_begin)
is called _after_ playing these zero-timed events.

> $ timidity -intl --segment 0:10,0:15 *.mid
> I think that it is recommended to refer to the processing of
> RC_FORWARD in playmidi.c.

Today was also the first time I used the -l (loop) option.
Good recommendation! - I added setting to tick_begin there as well.

> Regards,
> TAMUKI Shoichi

Thanks for helping with this segment-playing feature.
regards -- yotam

Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line

[TAMUKI S. <ta...@li...>]

Hello,

From: Yotam Medini ???? ????? <yot...@gm...>
Subject: Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line
Date: Sun, 19 Oct 2014 01:34:01 +0300

> Since I do not trust copy&paste of long patches
> into email message via Gmail web-interface I will keep sending pacthes
> separately.

I see, that makes sense.  I hope you to use standard e-mail tools in
the future, so that we may comment on specific portions of your code.

> In my next to be attached patch, I have reordered functions and
> documentation as you asked me to do.
> I have also:
> + simplified the parsing avoiding malloc/free.
> + Added example in the documentation.

Thank you for the revised patch.

> diff --git a/doc/C/timidity.1 b/doc/C/timidity.1
> index bdc6c2c..6345ac4 100644
> --- a/doc/C/timidity.1
> +++ b/doc/C/timidity.1
> @@ -997,7 +997,7 @@ Do not use rcpcv.dll (default).
>  .BI "\-x " str ", \-\-config\-string=" str
>  Configure \fBTiMidity++\fP with \fIstr\fP.  The format of \fIstr\fP is
>  the same as \fBtimidity.cfg\fP.
> -.sp
> +.s
>  For example:
>  .br
>  \fB\-x'bank 0\\n0 violin.pat'\fP

Perhaps, did you make a mistake there? (^_^;)

I tried your patch.  When playing with ncurses interface or something,
enabling --segment option will result in an incorrect display.

For example:

$ timidity -int --segment 0:25,1:21 06-purif.mid
$ timidity -intl --segment 0:10,0:15 *.mid

I think that it is recommended to refer to the processing of
RC_FORWARD in playmidi.c.

Regards,
TAMUKI Shoichi

Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line

[TAMUKI S. <ta...@li...>]

Hello,

From: Yotam Medini ???? ????? <yot...@gm...>
Subject: Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line
Date: Sun, 19 Oct 2014 01:20:46 +0300

> Let''s leave the issue of autoconf/automake to a separate thread.

Ok, but I would like you to submit patches with the latest source
tree.  Would you please use TiMidity++-2.14.0-140821-1200.tar.bz2
which is up to date, instead of TiMidity++-2.14.0.tar.bz2.

Regards,
TAMUKI Shoichi

Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line

[Yotam M. י. מ. <yot...@gm...>]

Hello Tamuki Shoichi,

Since I do not trust copy&paste of long patches
into email message via Gmail web-interface I will keep sending pacthes
separately.

In my next to be attached patch, I have reordered functions and
documentation as you asked me to do.
I have also:
+ simplified the parsing avoiding malloc/free.
+ Added example in the documentation.

By the way, why do we bother with prototype of static functions?
This like saying the same thing twice.
If we keep defining foo() before calling foo() there is no need
to declare foo() via prototype.
The only case where it is really necessary, when we have recursion via
cyclic calls.

regards -- yotam

On Sat, Oct 18, 2014 at 8:25 AM, TAMUKI Shoichi <ta...@li...> wrote:

> Hello,
>
> Thanks a lot.  You do not have to submit patches via direct to me.
> You can submit patches to timidity-devel using plain text format.
>
>
> Now, I am checking your patch again.
>
> In timidity.c, the option handling functions are sort by case-insensi-
> tive alphabetical order of the short options.  The --segment option
> is the second case that does not have short option.  FYI, the --module
> option is the first case of that.  Besides, the --segment option does
> not belong to -T option.  So, each code related to --segment option
> which you add, should be move to just after the code related to
> --module option.
>
> In timidity.c, time_parse() belongs to parse_opt_segment(). So, please
> exchange the order of the two functions and add the prototype of
> time_parse() just after the prototype of parse_opt_segment().
>
> Regards,
> TAMUKI Shoichi
>
>

Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line

[Yotam M. י. מ. <yot...@gm...>]

Let''s leave the issue of autoconf/automake to a separate thread.

On Sat, Oct 18, 2014 at 8:25 AM, TAMUKI Shoichi <ta...@li...> wrote:

> Hello,
>
> From: Yotam Medini ???? ????? <yot...@gm...>
> Subject: Re: [Timidity-devel] Fwd: patch: segment play, time-ticks
> skip+stop on command line
> Date: Fri, 17 Oct 2014 17:29:24 +0300
>
> > For now, I gave up on the ./autogen.sh and ./configure issue.
>
> If you use temporarily the older autoconf and automake environment,
> instead of your autoconf and automake environment, then you can use
> git clone and build with success.
>
> For example:
>
> $ cd
> $ tar xvpjf autoconf-2.59.tar.bz2
> $ ( cd autoconf-2.59 ; ./configure --prefix=~ && make && make install )
> $ tar xvpjf automake-1.7.6.tar.bz2
> $ ( cd automake-1.7.6 ; ./configure --prefix=~ && make && make install )
>
> After that, ~/bin, ~/share, ~/man, ~/info, and ~/lib directory are
> created.  And then,
>
> $ export PATH=~/bin:$PATH
> $ ...
>
> > As I commented, I use simple working tree extracted from the released
> > TiMidity++-2.14.0.tar.bz2.
> > If you would like me to try and test solution candidates, let me know.
>
> Or, You can also use the working tree extracted from the git-hourly
> tar ball which is automatically generated (up to date) and already
> autoreconf'ed.
>
>
> http://sourceforge.net/projects/timidity/files/TiMidity++/TiMidity++-git-hourly/
>
>

Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line

[TAMUKI S. <ta...@li...>]

Hello,

From: Yotam Medini ???? ????? <yot...@gm...>
Subject: Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line
Date: Fri, 17 Oct 2014 17:29:24 +0300

> Since timidity-devel@SF is CC;ed,
> I will attach a new patch 'K&R'-ed and TABed separately.
> 
> Note, that much of Timidity source code does not follow K&R and TAB use.
> 
> Personally, I do not mind K&R style, but I dislike TABs.
> The semantics of TABs leaves much to editors or browsers,
> and the resulted inconsistency is annoying.
> I consider them as unnecessary leftovers from the era of slow typewriters
> or space-bytes saving that may have been considered expensive.
> 
> But the coming patch will be as you have requested.

Thanks a lot.  You do not have to submit patches via direct to me.
You can submit patches to timidity-devel using plain text format.

> For now, I gave up on the ./autogen.sh and ./configure issue.

If you use temporarily the older autoconf and automake environment,
instead of your autoconf and automake environment, then you can use
git clone and build with success.

For example:

$ cd
$ tar xvpjf autoconf-2.59.tar.bz2
$ ( cd autoconf-2.59 ; ./configure --prefix=~ && make && make install )
$ tar xvpjf automake-1.7.6.tar.bz2
$ ( cd automake-1.7.6 ; ./configure --prefix=~ && make && make install )

After that, ~/bin, ~/share, ~/man, ~/info, and ~/lib directory are
created.  And then,

$ export PATH=~/bin:$PATH
$ ...

> As I commented, I use simple working tree extracted from the released
> TiMidity++-2.14.0.tar.bz2.
> If you would like me to try and test solution candidates, let me know.

Or, You can also use the working tree extracted from the git-hourly
tar ball which is automatically generated (up to date) and already
autoreconf'ed.

http://sourceforge.net/projects/timidity/files/TiMidity++/TiMidity++-git-hourly/

Now, I am checking your patch again.

In timidity.c, the option handling functions are sort by case-insensi-
tive alphabetical order of the short options.  The --segment option
is the second case that does not have short option.  FYI, the --module
option is the first case of that.  Besides, the --segment option does
not belong to -T option.  So, each code related to --segment option
which you add, should be move to just after the code related to
--module option.

In timidity.c, time_parse() belongs to parse_opt_segment(). So, please
exchange the order of the two functions and add the prototype of
time_parse() just after the prototype of parse_opt_segment().

Regards,
TAMUKI Shoichi

Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line

[Yotam M. י. מ. <yot...@gm...>]

Hello TAMUKI Shoichi,

Since timidity-devel@SF is CC;ed,
I will attach a new patch 'K&R'-ed and TABed separately.

Note, that much of Timidity source code does not follow K&R and TAB use.

Personally, I do not mind K&R style, but I dislike TABs.
The semantics of TABs leaves much to editors or browsers,
and the resulted inconsistency is annoying.
I consider them as unnecessary leftovers from the era of slow typewriters
or space-bytes saving that may have been considered expensive.

But the coming patch will be as you have requested.

For now, I gave up on the ./autogen.sh and ./configure issue.
As I commented, I use simple working tree extracted from the released
TiMidity++-2.14.0.tar.bz2.
If you would like me to try and test solution candidates, let me know.

regards -- yotam

On Fri, Oct 17, 2014 at 1:17 PM, TAMUKI Shoichi <ta...@li...> wrote:

> Hello,
>
> From: Yotam Medini ???? ????? <yot...@gm...>
> Date: Thu, 16 Oct 2014 11:20:55 +0300
> Subject: Re: [Timidity-devel] Fwd: patch: segment play, time-ticks
> skip+stop on command line
>
> > The segment playing feature still interests me.
> > Yes I know, almost two years passed...
> > Since I wish it would be added to future official releases,
> > I have improved it using your suggestions.
> >
> > An example, fetching and playing the 1st Tenor segment of
> >   http://www.learnchoralmusic.co.uk/Handel/Messiah/06-purif.mid
> > via
> >   $ timidity -idt --segment 0:25,1:21 06-purif.mid
> >
> > Attach is a patch. Could you please review it.
>
> Thank you for the patch.  I am going to review your patch.  However,
> I am too busy for now.  Please wait for a while.
>
> Ah, first of all, would you please try and do following points.
>
>   - Please keep K&R style.
>   - Please use tab to indent instead of spaces.
>
> By the way, what came of the ./autogen.sh and ./configure issue?
>
> Regards,
> TAMUKI Shoichi
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Timidity-devel mailing list
> Tim...@li...
> https://lists.sourceforge.net/lists/listinfo/timidity-devel
>

Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line

[TAMUKI S. <ta...@li...>]

Hello,

From: Yotam Medini ???? ????? <yot...@gm...>
Date: Thu, 16 Oct 2014 11:20:55 +0300
Subject: Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line

> The segment playing feature still interests me.
> Yes I know, almost two years passed...
> Since I wish it would be added to future official releases,
> I have improved it using your suggestions.
> 
> An example, fetching and playing the 1st Tenor segment of
>   http://www.learnchoralmusic.co.uk/Handel/Messiah/06-purif.mid
> via
>   $ timidity -idt --segment 0:25,1:21 06-purif.mid
> 
> Attach is a patch. Could you please review it.

Thank you for the patch.  I am going to review your patch.  However,
I am too busy for now.  Please wait for a while.

Ah, first of all, would you please try and do following points.

  - Please keep K&R style.
  - Please use tab to indent instead of spaces.

By the way, what came of the ./autogen.sh and ./configure issue?

Regards,
TAMUKI Shoichi

Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line

[Yotam M. י. מ. <yot...@gm...>]

Sending again the message _without_ the attachment
that somehow messed the view in sourceforge-mailing list.

Hello Tamuki Shoichi,

/* Working in tree extracted from released TiMidity++-2.14.0.tar.bz2 */

The segment playing feature still interests me.
Yes I know, almost two years passed...
Since I wish it would be added to future official releases,
I have improved it using your suggestions.

An example, fetching and playing the 1st Tenor segment of
  http://www.learnchoralmusic.co.uk/Handel/Messiah/06-purif.mid
via
  $ timidity -idt --segment 0:25,1:21 06-purif.mid

Attach is a patch. Could you please review it.

regards -- yotam

Re: [Timidity-devel] Fwd: patch: segment play, time-ticks skip+stop on command line

[Yotam M. י. מ. <yot...@gm...>]

diff --git a/doc/C/timidity.1 b/doc/C/timidity.1
index bdc6c2c..9304ae7 100644
--- a/doc/C/timidity.1
+++ b/doc/C/timidity.1
@@ -887,6 +887,15 @@ selected, depending on the implementation.
 Adjust tempo to \fIn\fP%; \fB120\fP play MOD files with an NTSC
 Amiga's timing.
 .TP
+.BI \-\-segment= begin[,end]
+Play just a sub-segment. comma separated time values of:
+\fIbegin\fP,\fIend\fP - defaulted to 0,infinity.
+Playing from \fIbegin\fP to \fIend\fP.
+.RS
+.TP
+Time format: \fI[<minutes>:]<seconds>[.<milliseconds>]\fP
+.RE
+.TP
 .BI "\-t " code ", \-\-output\-charset=" code
 Sets output coding of Japanese text.  Possible values of \fIcode\fP
 are:
diff --git a/timidity/playmidi.c b/timidity/playmidi.c
index 724cf6e..ed4f127 100644
--- a/timidity/playmidi.c
+++ b/timidity/playmidi.c
@@ -105,7 +105,7 @@ static int old_rate = -1;
 static int midi_streaming = 0;
 int volatile stream_max_compute = 500; /* compute time limit (in msec) when streaming */
 static int prescanning_flag;
-static int32 midi_restart_time = 0;
+static int32 midi_restart_time = 0; /* but see tick_begin */
 Channel channel[MAX_CHANNELS];
 int max_voices = DEFAULT_VOICES;
 Voice *voice = NULL;
@@ -126,6 +126,8 @@ int play_pause_flag = 0;
 static int file_from_stdin;
 int key_adjust = 0;
 FLOAT_T tempo_adjust = 1.0;
+static int32 tick_begin = 0;
+static int32 tick_end = 0x7fffffff;
 int opt_pure_intonation = 0;
 int current_freq_table = 0;
 int current_temper_freq_table = 0;
@@ -3162,6 +3164,18 @@ void play_midi_setup_drums(int ch, int note)
     reset_drum_controllers(channel[ch].drums, note);
 }
 
+static int32 mult_div1000(int32 a, int b)
+{
+    /* (a*B)/1000 but avoid overflow */
+    return (a / 1000)*b + ((a % 1000)*b + 1000/2)/1000;
+}
+
+void play_midi_set_segment(int ms_begin, int ms_end)
+{
+    tick_begin = mult_div1000(ms_begin, play_mode->rate);
+    tick_end = ms_end >= 0 ? mult_div1000(ms_end, play_mode->rate) : 0x7fffffff;
+}
+
 static void adjust_drum_panning(int ch, int note)
 {
     int i, uv = upper_voices;
@@ -6061,7 +6075,7 @@ static int playmidi_change_rate(int32 rate, int restart)
 	    midi_restart_time = current_sample;
     }
     else
-	midi_restart_time = 0;
+	midi_restart_time = tick_begin;
 
     arg = (int)rate;
     if(play_mode->acntl(PM_REQ_RATE, &arg) == -1)
@@ -6094,7 +6108,7 @@ void playmidi_output_changed(int play_state)
 	    midi_restart_time = current_sample;
     }
     else /* Not playing */
-	midi_restart_time = 0;
+	midi_restart_time = tick_begin;
 
     if(play_state != 2)
     {
@@ -6362,7 +6376,7 @@ static int apply_controls(void)
 	  case RC_RESTART:	/* |<< */
 	    if(play_pause_flag)
 	    {
-		midi_restart_time = 0;
+		midi_restart_time = tick_begin;
 		ctl_pause_event(1, 0);
 		continue;
 	    }
@@ -6370,7 +6384,7 @@ static int apply_controls(void)
 	    skip_to(0);
 	    ctl_updatetime(0);
 	    jump_flag = 1;
-		midi_restart_time = 0;
+		midi_restart_time = tick_begin;
 	    continue;
 
 	  case RC_JUMP:
@@ -6410,8 +6424,8 @@ static int apply_controls(void)
 	    if(play_pause_flag)
 	    {
 		midi_restart_time -= val;
-		if(midi_restart_time < 0)
-		    midi_restart_time = 0;
+		if(midi_restart_time < tick_begin)
+		    midi_restart_time = tick_begin;
 		ctl_pause_event(1, midi_restart_time);
 		continue;
 	    }
@@ -6428,7 +6442,7 @@ static int apply_controls(void)
 	    {
 		skip_to(0);
 		ctl_updatetime(0);
-		midi_restart_time = 0;
+		midi_restart_time = tick_begin;
 	    }
 	    return RC_JUMP;
 
@@ -8283,7 +8297,7 @@ static int play_midi(MidiEvent *eventlist, int32 samples)
     if(RC_IS_SKIP_FILE(rc))
 	return rc;
 
-    skip_to(midi_restart_time);
+    skip_to(tick_begin * midi_time_ratio);
 
     if(midi_restart_time > 0) { /* Need to update interface display */
       int i;
@@ -8293,11 +8307,12 @@ static int play_midi(MidiEvent *eventlist, int32 samples)
     rc = RC_NONE;
     for(;;)
     {
-	midi_restart_time = 1;
+	midi_restart_time = tick_begin + 1;
 	rc = play_event(current_event);
-	if(rc != RC_NONE)
+	if ((rc != RC_NONE) || (current_event->time > tick_end))
 	    break;
-	if (midi_restart_time)    /* don't skip the first event if == 0 */
+	/* don't skip the first event if == 0 */
+	if (midi_restart_time > tick_begin)
 	    current_event++;
     }
 
@@ -8529,7 +8544,7 @@ int play_midi_file(char *fn)
 		FILL_CHANNELMASK(channel_mute);
 
     /* Reset restart offset */
-    midi_restart_time = 0;
+    midi_restart_time = tick_begin;
 
 #ifdef REDUCE_VOICE_TIME_TUNING
     /* Reset voice reduction stuff */
@@ -8807,7 +8822,7 @@ void playmidi_stream_init(void)
     CLEAR_CHANNELMASK(channel_mute);
 	if (temper_type_mute & 1)
 		FILL_CHANNELMASK(channel_mute);
-    midi_restart_time = 0;
+    midi_restart_time = tick_begin;
     if(first)
     {
 	first = 0;
diff --git a/timidity/playmidi.h b/timidity/playmidi.h
index f5cb0f8..f91c082 100644
--- a/timidity/playmidi.h
+++ b/timidity/playmidi.h
@@ -595,6 +595,7 @@ extern void midi_program_change(int ch, int prog);
 extern void free_voice(int v);
 extern void free_reverb_buffer(void);
 extern void play_midi_setup_drums(int ch,int note);
+extern void play_midi_set_segment(int ms_begin, int ms_end);
 
 /* For stream player */
 extern void playmidi_stream_init(void);
diff --git a/timidity/timidity.c b/timidity/timidity.c
index 4a4d601..111a4ad 100644
--- a/timidity/timidity.c
+++ b/timidity/timidity.c
@@ -200,6 +200,7 @@ enum {
 	TIM_OPT_CACHE_SIZE,
 	TIM_OPT_SAMPLE_FREQ,
 	TIM_OPT_ADJUST_TEMPO,
+	TIM_OPT_SEGMENT,
 	TIM_OPT_CHARSET,
 	TIM_OPT_UNLOAD_INST,
 	TIM_OPT_VOLUME_CURVE,
@@ -350,6 +351,7 @@ static const struct option longopts[] = {
 	{ "cache-size",             required_argument, NULL, TIM_OPT_CACHE_SIZE },
 	{ "sampling-freq",          required_argument, NULL, TIM_OPT_SAMPLE_FREQ },
 	{ "adjust-tempo",           required_argument, NULL, TIM_OPT_ADJUST_TEMPO },
+	{ "segment",                required_argument, NULL, TIM_OPT_SEGMENT },
 	{ "output-charset",         required_argument, NULL, TIM_OPT_CHARSET },
 	{ "no-unload-instruments",  no_argument,       NULL, TIM_OPT_UNLOAD_INST },
 	{ "unload-instruments",     optional_argument, NULL, TIM_OPT_UNLOAD_INST },
@@ -501,6 +503,7 @@ static inline int parse_opt_R(const char *);
 static inline int parse_opt_S(const char *);
 static inline int parse_opt_s(const char *);
 static inline int parse_opt_T(const char *);
+static inline int parse_opt_segment(const char *);
 static inline int parse_opt_t(const char *);
 static inline int parse_opt_U(const char *);
 static inline int parse_opt_volume_curve(char *);
@@ -633,6 +636,9 @@ extern char* pcm_alternate_file;
 extern double atof(const char *);
 #endif
 
+static int32 segment_begin = -1; /* in milliseconds */
+static int32 segment_end = -1; /* in milliseconds */
+
 /*! copy bank and, if necessary, map appropriately */
 static void copybank(ToneBank *to, ToneBank *from, int mapid, int bankmapfrom, int bankno)
 {
@@ -2905,6 +2911,8 @@ MAIN_INTERFACE int set_tim_opt_long(int c, char *optarg, int index)
 		return parse_opt_s(arg);
 	case TIM_OPT_ADJUST_TEMPO:
 		return parse_opt_T(arg);
+	case TIM_OPT_SEGMENT:
+		return parse_opt_segment(arg);
 	case TIM_OPT_CHARSET:
 		return parse_opt_t(arg);
 	case TIM_OPT_UNLOAD_INST:
@@ -3841,6 +3849,11 @@ static int parse_opt_h(const char *arg)
 "  -T n       --adjust-tempo=n",
 "               Adjust tempo to n%%,",
 "                 120=play MOD files with an NTSC Amiga's timing",
+"             --segment=<begin>[,<end>]",
+"               Play just a sub-segment. comma separated time values of:",
+"               <begin>, <end> - defaulted to 0,infinity",
+"               Playing from <begin> to <end>",
+"               Time format: [<minutes>:]<seconds>[.<milliseconds>]",
 "  -t code    --output-charset=code",
 "               Output text language code:",
 "                 code=auto  : Auto conversion by `LANG' environment variable",
@@ -4760,6 +4773,99 @@ static inline int parse_opt_T(const char *arg)
 	return 0;
 }
 
+static int time_parse(int32 *pms, const char *a, int defval)
+{
+	int ret = 0, sec = 0, ms = 0;
+	unsigned u;
+	char *endptr;
+
+	u = strtoul(a, &endptr, 10);
+	if (endptr == a)
+	{
+	    *pms = defval;
+	}
+	else
+	{
+	    if (*endptr == '\0')
+	    {
+	        sec = u;
+	    }
+	    else
+	    {
+	        char c = *endptr;
+
+	        a = endptr + 1;
+	        if (c == ':')
+	        {
+	            sec = 60*u;
+	            u = strtoul(a, &endptr, 10);
+	            if ((endptr == a) || (u >= 60))
+	            {
+	                ret = 1;
+	            }
+	            else
+	            {
+	                sec += u;
+	                c = *endptr;
+	                a = endptr + 1;
+	            }
+	        }
+	        else
+	        {
+	            sec = u;
+	        }
+	        if (c == '.')
+	        {
+	            ms = strtoul(a, &endptr, 10);
+	            if ((endptr == a) || (ms >= 1000))
+	            {
+	                ret = 1;
+	            }
+	        }
+	    }
+	    if (!ret)
+	    {
+	        *pms = 1000*sec + ms;
+	    }
+	    
+	}
+	return ret;
+}
+
+static inline int parse_opt_segment(const char *arg)
+{
+	/* Set segment milliseconds for begin,end */
+	int ret = 0;
+	char *comma = strchr(arg, ',');
+
+	if (comma)
+	{
+	    int blen = comma - arg;
+	    char *b = (char *)safe_malloc(blen + 1);
+
+	    strncpy(b, arg, blen);
+	    if (time_parse(&segment_begin, b, 0) ||
+	        time_parse(&segment_end, comma + 1, -1))
+	    {
+		ctl->cmsg(CMSG_ERROR, VERB_NORMAL,
+				"Time Segment format error", *arg);
+	        ret = 1;
+	    }
+	    free(b);
+	}
+	else
+	{
+	    if (time_parse(&segment_begin, arg, 0))
+	    {
+	        ret = 1;
+		ctl->cmsg(CMSG_ERROR, VERB_NORMAL,
+				"Time Segment Begin format error", *arg);
+	    }
+	}
+
+	return ret;
+}
+
 static inline int parse_opt_t(const char *arg)
 {
 	if (output_text_code)
@@ -5473,6 +5579,10 @@ MAIN_INTERFACE void timidity_init_player(void)
 	play_mode->rate = opt_output_rate;
     else if(play_mode->rate == 0)
 	play_mode->rate = DEFAULT_RATE;
+    if (segment_begin >= 0)
+    {
+        play_midi_set_segment(segment_begin, segment_end);
+    }
 
     /* save defaults */
     COPY_CHANNELMASK(drumchannels, default_drumchannels);

Re: [Timidity-devel] How to build? ./autogen.sh & ./configure fail

[Yotam M. י. מ. <yot...@gm...>]

Hello TAMUKI Shoichi,

I tried the hack in the link you sent.
I have put it in the atatched script ka_conf-build.sh.

The attached script ka_conf-build.sh consists of the hack in the link you
sent.
  http://qiita.com/ka_/items/9791131cdd538867bfd6
Running it resulted with failures. The ka_conf-build.log is attached as
well.

For those who do not get access to the attachments,
a summary is appended.

regards -- yotam


+ touch Makefile.am
+ autoscan
utils/support.c:676: warning: getwd is deprecated, use getcwd instead
configure.in: warning: missing AC_CHECK_FUNCS([fchdir]) wanted by:
timidity/timidity.c:4108
configure.in: warning: missing AC_CHECK_FUNCS([setenv]) wanted by:
timidity/esd_a.c:104
configure.in: warning: missing AC_CHECK_FUNCS([strcspn]) wanted by:
timidity/timidity.c:1301
configure.in: warning: missing AC_CHECK_FUNCS([strpbrk]) wanted by:
timidity/timidity.c:785
configure.in: warning: missing AC_CHECK_FUNCS([strtoul]) wanted by:
utils/getaddrinfo.c:467
configure.in: warning: missing AC_CHECK_HEADER_STDBOOL wanted by:
windrv/timiwp_timidity.c:7
configure.in: warning: missing AC_FUNC_ALLOCA wanted by:
windrv/timiditydrv.c:346
configure.in: warning: missing AC_FUNC_MALLOC wanted by:
utils/getaddrinfo.c:291
configure.in: warning: missing AC_FUNC_REALLOC wanted by:
libunimod/load_xm.c:599
...
+ mv configure.scan configure.ac
+ autoconf
autoconf: warning: both `configure.ac' and `configure.in' are present.
autoconf: warning: proceeding with `configure.ac'.
+ touch INSTALL
+ aclocal
aclocal: warning: autoconf input should be named 'configure.ac', not '
configure.in'
aclocal: warning: 'configure.ac' and 'configure.in' both present.
aclocal: proceeding with 'configure.ac'
+ autoconf
autoconf: warning: both `configure.ac' and `configure.in' are present.
autoconf: warning: proceeding with `configure.ac'.
+ automake -a
automake: warning: autoconf input should be named 'configure.ac', not '
configure.in'
automake: warning: 'configure.ac' and 'configure.in' both present.
automake: proceeding with 'configure.ac'
configure.ac:11: installing './compile'
configure.ac:6: installing './install-sh'
configure.ac:6: installing './missing'
configure.ac:8: error: required file 'config.h.in' not found
interface/Makefile.am:32: error: W32G_GUI does not appear in AM_CONDITIONAL
interface/Makefile.am:138: error: ENABLE_WRD does not appear in
AM_CONDITIONAL
...
interface/Makefile.am:362: error: NEEDDLOPEN does not appear in
AM_CONDITIONAL
interface/Makefile.am:25: warning: 'INCLUDES' is the old name for
'AM_CPPFLAGS' (or '*_CPPFLAGS')
automake: warning: autoconf input should be named 'configure.ac', not '
configure.in'
automake: warning: 'configure.ac' and 'configure.in' both present.
automake: proceeding with 'configure.ac'
interface/Makefile.am:30: error: library used but 'RANLIB' is undefined
interface/Makefile.am:30:   The usual way to define 'RANLIB' is to add
'AC_PROG_RANLIB'
interface/Makefile.am:30:   to 'configure.ac' and run 'autoconf' again.
interface/Makefile.am: installing './depcomp'
libarc/Makefile.am:62: error: ENABLE_NETWORK does not appear in
AM_CONDITIONAL
...
libunimod/Makefile.am:21: warning: 'INCLUDES' is the old name for
'AM_CPPFLAGS' (or '*_CPPFLAGS')
libunimod/Makefile.am:28: error: library used but 'RANLIB' is undefined
libunimod/Makefile.am:28:   The usual way to define 'RANLIB' is to add
'AC_PROG_RANLIB'
libunimod/Makefile.am:28:   to 'configure.ac' and run 'autoconf' again.
timidity/Makefile.am:168: error: BORLANDC does not appear in AM_CONDITIONAL
...
utils/Makefile.am:114: error: POCC does not appear in AM_CONDITIONAL
utils/Makefile.am:21: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS'
(or '*_CPPFLAGS')
utils/Makefile.am:25: error: library used but 'RANLIB' is undefined
utils/Makefile.am:25:   The usual way to define 'RANLIB' is to add
'AC_PROG_RANLIB'
utils/Makefile.am:25:   to 'configure.ac' and run 'autoconf' again.
windrv/Makefile.am:32: error: WINDRV does not appear in AM_CONDITIONAL
...
windrv/Makefile.am:23: warning: 'INCLUDES' is the old name for
'AM_CPPFLAGS' (or '*_CPPFLAGS')
windrv/Makefile.am:34: error: library used but 'RANLIB' is undefined
windrv/Makefile.am:34:   The usual way to define 'RANLIB' is to add
'AC_PROG_RANLIB'
windrv/Makefile.am:34:   to 'configure.ac' and run 'autoconf' again.
+ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
...
checking for strtoul... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: error: cannot find input file: `Makefile.in'
+ make
make: *** No targets specified and no makefile found.  Stop.


On Wed, Oct 15, 2014 at 2:43 AM, TAMUKI Shoichi <ta...@li...> wrote:

> Hello,
>
> From: Yotam Medini ???? ????? <yot...@gm...>
> Subject: [Timidity-devel] How to build? ./autogen.sh & ./configure fail
> Date: Wed, 15 Oct 2014 01:57:50 +0300
>
> > After
> >   $ git clone git://git.code.sf.net/p/timidity/git timidity-git
> >
> > Running:
> >   $ ./autogen.sh
> > starts with some warning messages:
> >
> > (snip)
> >
> > On my box:
> >     $ autoconf --version
> >     autoconf (GNU Autoconf) 2.69
> >
> >     $ automake --version
> >     automake (GNU automake) 1.14.1
>
> Would you try the following workaround?
>
> http://qiita.com/ka_/items/9791131cdd538867bfd6
>
> Regards,
> TAMUKI Shoichi
>

Re: [Timidity-devel] How to build? ./autogen.sh & ./configure fail

[TAMUKI S. <ta...@li...>]

Hello,

From: Yotam Medini ???? ????? <yot...@gm...>
Subject: [Timidity-devel] How to build? ./autogen.sh & ./configure fail
Date: Wed, 15 Oct 2014 01:57:50 +0300

> After
>   $ git clone git://git.code.sf.net/p/timidity/git timidity-git
> 
> Running:
>   $ ./autogen.sh
> starts with some warning messages:
> 
> (snip)
> 
> On my box:
>     $ autoconf --version
>     autoconf (GNU Autoconf) 2.69
> 
>     $ automake --version
>     automake (GNU automake) 1.14.1

Would you try the following workaround?

http://qiita.com/ka_/items/9791131cdd538867bfd6

Regards,
TAMUKI Shoichi

[Timidity-devel] How to build? ./autogen.sh & ./configure fail

[Yotam M. י. מ. <yot...@gm...>]

After
  $ git clone git://git.code.sf.net/p/timidity/git timidity-git

Running:
  $ ./autogen.sh
starts with some warning messages:

  aclocal: warning: autoconf input should be named 'configure.ac', not '
configure.in'
  automake: warning: autoconf input should be named 'configure.ac', not '
configure.in'
  Makefile.am: installing './INSTALL'
  Makefile.am: error: required file './ChangeLog' not found
  interface/Makefile.am:25: warning: 'INCLUDES' is the old name for
'AM_CPPFLAGS' (or '*_CPPFLAGS')
  automake: warning: autoconf input should be named 'configure.ac', not '
configure.in'
  libarc/Makefile.am:21: warning: 'INCLUDES' is the old name for
'AM_CPPFLAGS' (or '*_CPPFLAGS')
  libunimod/Makefile.am:21: warning: 'INCLUDES' is the old name for
'AM_CPPFLAGS' (or '*_CPPFLAGS')
  timidity/Makefile.am:21: warning: 'INCLUDES' is the old name for
'AM_CPPFLAGS' (or '*_CPPFLAGS')
  utils/Makefile.am:21: warning: 'INCLUDES' is the old name for
'AM_CPPFLAGS' (or '*_CPPFLAGS')
  windrv/Makefile.am:23: warning: 'INCLUDES' is the old name for
'AM_CPPFLAGS' (or '*_CPPFLAGS')
  autoreconf: automake failed with exit status: 1

and finally it fails with:
  config.status: error: cannot find input file: `Makefile.in'

On my box:
    $ autoconf --version
    autoconf (GNU Autoconf) 2.69

    $ automake --version
    automake (GNU automake) 1.14.1