timidity-devel — Timidity Development mailing list

Re: [Timidity-devel] SoundFont lager than 2GB

[SATO K. <ke...@ra...>]

I have added support of soundfonts over 2GiB for Linux x86_64, and other L64s.
This is actually a bug fix of dealing soundfonts.

> It's a good thing.
> The developers of timidity41 may have information about where fixes are needed.

Thank you for letting me know it, Noike-san.
I myself don't have a concrete plan of extending support to the remaining
platforms, or in fact, how it should be implemented as a whole for better
maintainability (say, either libarc API to be changed or extended).

I had read the pointed thread briefly and
I guess they took whatever akin to the former path.

Fri, 3 May 2024 15:38:48 +0900 Kenzi NOIKE <kn...@gm...>:
>
> Mr. SATO,
>
> Thank you for your reply, it clarified the cause of the problem.
>
> I asked the same question to the developers of timidity41, which is a
> fork project of TiMidity++.
>
> https://github.com/starg2/timidity41/discussions/4
>
> As a result, I got answer that timidity41 already support SoundFont over 2GiB.
> So I am considering using timidity41 instead of TiMidity++.
> However, since it is designed for Windows enviroment currently, it
> needs to be modified for Linux.
> I plan to do that work at later.
>
>
> > Just saying for now, but I'm thinking of looking more into it later.
>
> It's a good thing.
> The developers of timidity41 may have information about where fixes are needed.
>
>
>
> 2024年5月2日(木) 20:38 SATO Kentaro <ke...@ra...>:
> >
> > Hi,
> >
> > >Does anyone know that if TiMidity++ can handle SoundFont lager than 2GB?
> >
> > TiMidity++ cannot deal with soundfonts over 2GiB.
> > At a glance, it isn't as simple as how "stop using signed integers"
> > sounds, to implement on every supported environment.
> > But for Linux x86_64, it appears to be possible with some fixes.
> >
> > Just saying for now, but I'm thinking of looking more into it later.
> >
> >
> > Tue, 30 Apr 2024 17:33:33 +0900 Kenzi NOIKE <kn...@gm...>:
> >
> >
> > >
> > > Dear developper,
> > >
> > > Does anyone know that if TiMidity++ can handle SoundFont lager than 2GB?
> > >
> > > I tried to use HiDef SoundFont with TiMidity++ on 64bit Linux.
> > > However, some errors occurred and it could not be loaded.
> > > The file size of Hidef SoundFont is approximately 4GB.
> > > I think that this was because the file size of SoundFont was too large.
> > >
> > > To clarify the cause, I want to know if TiMidity++ can handle
> > > SoundFont lager than 2GB.
> > >
> > > As an additional Infomation,
> > > It seems that FluidSynth became handle over 2GB SoundFont around
> > > version 2.2.0 to 2.2.2.
> > >
> > >
> > > Error msgs:
> > > Trying to open /usr/local/share/timidity/HiDef/HiDef_20190525.sf2
> > > INFO:
> > >  ifil:
> > >   version 2, minor 4
> > >  isng:
> > >   E-mu 10K1
> > >  INAM:
> > >   name 4GBC&C50_tmp.sf2
> > >  ICRD:
> > >   2/29/2016 2:48:21 AM
> > >  IENG:
> > >   SynthFont Viena
> > >  IPRD:
> > >   SynthFont Viena
> > >  ICOP:
> > >   SynthFont Viena
> > >  ISFT:
> > >   Polyphone
> > > sdta:
> > > /usr/local/share/timidity/HiDef/HiDef_20190525.sf2: *** illegal id in
> > > level 0: smpl -1471800400
> > > /usr/local/share/timidity/HiDef/HiDef_20190525.sf2: *** illegal bags / gens
> > >
> > >
> > > HiDef SoundFont:
> > > https://musical-artifacts.com/artifacts/2525
> > >
> > > --
> > > // Kenzi NOIKE
> > >
> > >
> > > _______________________________________________
> > > Timidity-devel mailing list
> > > Tim...@li...
> > > https://lists.sourceforge.net/lists/listinfo/timidity-devel
> > >
> > >
> >
> >
> > _______________________________________________
> > Timidity-devel mailing list
> > Tim...@li...
> > https://lists.sourceforge.net/lists/listinfo/timidity-devel
>
>
>
> --
> // Kenzi NOIKE
>
>

Re: [Timidity-devel] SoundFont lager than 2GB

[Kenzi N. <kn...@gm...>]

Mr. SATO,

Thank you for your reply, it clarified the cause of the problem.

I asked the same question to the developers of timidity41, which is a
fork project of TiMidity++.

https://github.com/starg2/timidity41/discussions/4

As a result, I got answer that timidity41 already support SoundFont over 2GiB.
So I am considering using timidity41 instead of TiMidity++.
However, since it is designed for Windows enviroment currently, it
needs to be modified for Linux.
I plan to do that work at later.


> Just saying for now, but I'm thinking of looking more into it later.

It's a good thing.
The developers of timidity41 may have information about where fixes are needed.



2024年5月2日(木) 20:38 SATO Kentaro <ke...@ra...>:
>
> Hi,
>
> >Does anyone know that if TiMidity++ can handle SoundFont lager than 2GB?
>
> TiMidity++ cannot deal with soundfonts over 2GiB.
> At a glance, it isn't as simple as how "stop using signed integers"
> sounds, to implement on every supported environment.
> But for Linux x86_64, it appears to be possible with some fixes.
>
> Just saying for now, but I'm thinking of looking more into it later.
>
>
> Tue, 30 Apr 2024 17:33:33 +0900 Kenzi NOIKE <kn...@gm...>:
>
>
> >
> > Dear developper,
> >
> > Does anyone know that if TiMidity++ can handle SoundFont lager than 2GB?
> >
> > I tried to use HiDef SoundFont with TiMidity++ on 64bit Linux.
> > However, some errors occurred and it could not be loaded.
> > The file size of Hidef SoundFont is approximately 4GB.
> > I think that this was because the file size of SoundFont was too large.
> >
> > To clarify the cause, I want to know if TiMidity++ can handle
> > SoundFont lager than 2GB.
> >
> > As an additional Infomation,
> > It seems that FluidSynth became handle over 2GB SoundFont around
> > version 2.2.0 to 2.2.2.
> >
> >
> > Error msgs:
> > Trying to open /usr/local/share/timidity/HiDef/HiDef_20190525.sf2
> > INFO:
> >  ifil:
> >   version 2, minor 4
> >  isng:
> >   E-mu 10K1
> >  INAM:
> >   name 4GBC&C50_tmp.sf2
> >  ICRD:
> >   2/29/2016 2:48:21 AM
> >  IENG:
> >   SynthFont Viena
> >  IPRD:
> >   SynthFont Viena
> >  ICOP:
> >   SynthFont Viena
> >  ISFT:
> >   Polyphone
> > sdta:
> > /usr/local/share/timidity/HiDef/HiDef_20190525.sf2: *** illegal id in
> > level 0: smpl -1471800400
> > /usr/local/share/timidity/HiDef/HiDef_20190525.sf2: *** illegal bags / gens
> >
> >
> > HiDef SoundFont:
> > https://musical-artifacts.com/artifacts/2525
> >
> > --
> > // Kenzi NOIKE
> >
> >
> > _______________________________________________
> > Timidity-devel mailing list
> > Tim...@li...
> > https://lists.sourceforge.net/lists/listinfo/timidity-devel
> >
> >
>
>
> _______________________________________________
> Timidity-devel mailing list
> Tim...@li...
> https://lists.sourceforge.net/lists/listinfo/timidity-devel



-- 
// Kenzi NOIKE

Re: [Timidity-devel] SoundFont lager than 2GB

[SATO K. <ke...@ra...>]

Hi,

>Does anyone know that if TiMidity++ can handle SoundFont lager than 2GB?

TiMidity++ cannot deal with soundfonts over 2GiB.
At a glance, it isn't as simple as how "stop using signed integers"
sounds, to implement on every supported environment.
But for Linux x86_64, it appears to be possible with some fixes.

Just saying for now, but I'm thinking of looking more into it later.


Tue, 30 Apr 2024 17:33:33 +0900 Kenzi NOIKE <kn...@gm...>:


>
> Dear developper,
>
> Does anyone know that if TiMidity++ can handle SoundFont lager than 2GB?
>
> I tried to use HiDef SoundFont with TiMidity++ on 64bit Linux.
> However, some errors occurred and it could not be loaded.
> The file size of Hidef SoundFont is approximately 4GB.
> I think that this was because the file size of SoundFont was too large.
>
> To clarify the cause, I want to know if TiMidity++ can handle
> SoundFont lager than 2GB.
>
> As an additional Infomation,
> It seems that FluidSynth became handle over 2GB SoundFont around
> version 2.2.0 to 2.2.2.
>
>
> Error msgs:
> Trying to open /usr/local/share/timidity/HiDef/HiDef_20190525.sf2
> INFO:
>  ifil:
>   version 2, minor 4
>  isng:
>   E-mu 10K1
>  INAM:
>   name 4GBC&C50_tmp.sf2
>  ICRD:
>   2/29/2016 2:48:21 AM
>  IENG:
>   SynthFont Viena
>  IPRD:
>   SynthFont Viena
>  ICOP:
>   SynthFont Viena
>  ISFT:
>   Polyphone
> sdta:
> /usr/local/share/timidity/HiDef/HiDef_20190525.sf2: *** illegal id in
> level 0: smpl -1471800400
> /usr/local/share/timidity/HiDef/HiDef_20190525.sf2: *** illegal bags / gens
>
>
> HiDef SoundFont:
> https://musical-artifacts.com/artifacts/2525
>
> --
> // Kenzi NOIKE
>
>
> _______________________________________________
> Timidity-devel mailing list
> Tim...@li...
> https://lists.sourceforge.net/lists/listinfo/timidity-devel
>
>

[Timidity-devel] SoundFont lager than 2GB

[Kenzi N. <kn...@gm...>]

Dear developper,

Does anyone know that if TiMidity++ can handle SoundFont lager than 2GB?

I tried to use HiDef SoundFont with TiMidity++ on 64bit Linux.
However, some errors occurred and it could not be loaded.
The file size of Hidef SoundFont is approximately 4GB.
I think that this was because the file size of SoundFont was too large.

To clarify the cause, I want to know if TiMidity++ can handle
SoundFont lager than 2GB.

As an additional Infomation,
It seems that FluidSynth became handle over 2GB SoundFont around
version 2.2.0 to 2.2.2.


Error msgs:
Trying to open /usr/local/share/timidity/HiDef/HiDef_20190525.sf2
INFO:
 ifil:
  version 2, minor 4
 isng:
  E-mu 10K1
 INAM:
  name 4GBC&C50_tmp.sf2
 ICRD:
  2/29/2016 2:48:21 AM
 IENG:
  SynthFont Viena
 IPRD:
  SynthFont Viena
 ICOP:
  SynthFont Viena
 ISFT:
  Polyphone
sdta:
/usr/local/share/timidity/HiDef/HiDef_20190525.sf2: *** illegal id in
level 0: smpl -1471800400
/usr/local/share/timidity/HiDef/HiDef_20190525.sf2: *** illegal bags / gens


HiDef SoundFont:
https://musical-artifacts.com/artifacts/2525

-- 
// Kenzi NOIKE

Re: [Timidity-devel] Patching autoconf fragments for C99 compatibility

[Kenzi N. <kn...@gm...>]

> Some time ago, our Linux distribution development server
> suffered a severe failure.  Fortunately, the data remains intact, and
> most of the functions necessary for development have been restored,
> but the TiMidity++ hourly tarball release mechanism remains suspended.
> Restoration is delayed due to the low patch volume.

It may be better to use GitHub Action
rather than utilize self-hosted "the TiMidity++ hourly tarball release
mechanism"
at the viewpoint of ease of maintenance and continuity,
if there are no problems to repository moving to GitHub from SourceForge.
I'm not familiar with GitHub Action very well,
but other OSS communities use it conveniently.


2023年3月5日(日) 18:50 TAMUKI Shoichi <ta...@li...>:
>
> Hello Jonathan-san and all,
>
> I am one of the members involved in the development and maintenance of
> TiMidity++.  Due to personal circumstances, the frequency of receiving
> E-mails has decreased.  I apologize for the delay in replying from the
> TiMidity++ development members and causing everyone concern.
>
> Around the beginning of 2000, MIDI and its peripheral standards such
> as SMF were widely used by general users and industry people.
> However, due to various factors, the number of users using other
> standards and formats increased, and it seemed that MIDI was gradually
> dying out, especially in Japan.  It seems that the TiMidity++
> development members who were busy at the time have gradually faded out
> and are now active in various fields.  Nonetheless, there is universal
> demand for MIDI among core users and industry people, and I believe
> that TiMidity++ has a reason for existence.  I believe other
> TiMidity++ developers have similar thoughts.
>
> By the way, I'm working with another group of people to develop our
> own Linux distribution based on Slackware.  TiMidity++ is one of the
> major packages in the Linux distribution's multimedia category.  Of
> course, we also maintain packages such as libtimidity, SDL_sound, and
> SDL_mixer.  I didn't know about Open Cubic Player UNIX version, but
> it looks interesting software, so I'd like to try it someday.  I run
> the TiMidity++ hourly tarball release mechanism on our Linux
> distribution development server.  It checks for patch commits every
> hour, performs a compilation test if there is an update, and uploads a
> tarball.  Some time ago, our Linux distribution development server
> suffered a severe failure.  Fortunately, the data remains intact, and
> most of the functions necessary for development have been restored,
> but the TiMidity++ hourly tarball release mechanism remains suspended.
> Restoration is delayed due to the low patch volume.
>
> Jonathan-san, thank you very much for sending us the patch that fix
> code that relies on obsolete C89 features such as implicit function
> declarations and implicit ints.  It looks good to me.  I would like to
> commit this patch, but I am hesitant because the TiMidity++ hourly
> tarball release mechanism is stopped as mentioned above.  I would like
> to restore it as soon as possible, so please wait for a while.  Not
> only will we accept compilation issues like this one and security
> patches, but we will also work on extending features and implementing
> new features in line with the current situation.
>
> From: Ozkan Sezer <se...@gm...>
> Subject: Re: [Timidity-devel] timidity-devel shout out for main-developer
> Date: Tue, 21 Feb 2023 20:40:15 +0300
>
> > My interest is that I'm maintaining libtimidity:
> >
> > https://sourceforge.net/projects/libtimidity/
> > mirror: https://github.com/sezero/libtimidity
> >
> > ... which is a fork from old SDL_sound which in turn had it forked from
> > old timidity-0.2i, with additional fixes such as
> > https://web.archive.org/web/20170824103526/http://www.onicos.com/staff/iz/timidity/dist/timidity-0.2i-bugfix.pat
> > (that onicos.com archive seems have been gone, unfortunately, hence the
> > archive.org link) and few additional bits from timidity++. Also applied
> > an initial soundfont patch of Takashi Iwai to libtimidity (in soundfont
> > branch), but keeping it as devel for now for lack of timidity++ config
> > compatibility in it yet.
>
> Ozkan-san, the site above has moved:
>
> http://www33146ue.sakura.ne.jp/staff/iz/timidity/dist/timidity-0.2i-bugfix.pat
>
> Regards,
> TAMUKI Shoichi
>
>
> _______________________________________________
> Timidity-devel mailing list
> Tim...@li...
> https://lists.sourceforge.net/lists/listinfo/timidity-devel



-- 
// Kenzi NOIKE

Re: [Timidity-devel] Patching autoconf fragments for C99 compatibility

[Ozkan S. <se...@gm...>]

> Ozkan-san, the site above has moved:
>
> http://www33146ue.sakura.ne.jp/staff/iz/timidity/dist/timidity-0.2i-bugfix.pat
>
> Regards,
> TAMUKI Shoichi

Thank you !

Re: [Timidity-devel] Patching autoconf fragments for C99 compatibility

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

Hello Jonathan-san and all,

I am one of the members involved in the development and maintenance of
TiMidity++.  Due to personal circumstances, the frequency of receiving
E-mails has decreased.  I apologize for the delay in replying from the
TiMidity++ development members and causing everyone concern.

Around the beginning of 2000, MIDI and its peripheral standards such
as SMF were widely used by general users and industry people.
However, due to various factors, the number of users using other
standards and formats increased, and it seemed that MIDI was gradually
dying out, especially in Japan.  It seems that the TiMidity++
development members who were busy at the time have gradually faded out
and are now active in various fields.  Nonetheless, there is universal
demand for MIDI among core users and industry people, and I believe
that TiMidity++ has a reason for existence.  I believe other
TiMidity++ developers have similar thoughts.

By the way, I'm working with another group of people to develop our
own Linux distribution based on Slackware.  TiMidity++ is one of the
major packages in the Linux distribution's multimedia category.  Of
course, we also maintain packages such as libtimidity, SDL_sound, and
SDL_mixer.  I didn't know about Open Cubic Player UNIX version, but
it looks interesting software, so I'd like to try it someday.  I run
the TiMidity++ hourly tarball release mechanism on our Linux
distribution development server.  It checks for patch commits every
hour, performs a compilation test if there is an update, and uploads a
tarball.  Some time ago, our Linux distribution development server
suffered a severe failure.  Fortunately, the data remains intact, and
most of the functions necessary for development have been restored,
but the TiMidity++ hourly tarball release mechanism remains suspended.
Restoration is delayed due to the low patch volume.

Jonathan-san, thank you very much for sending us the patch that fix
code that relies on obsolete C89 features such as implicit function
declarations and implicit ints.  It looks good to me.  I would like to
commit this patch, but I am hesitant because the TiMidity++ hourly
tarball release mechanism is stopped as mentioned above.  I would like
to restore it as soon as possible, so please wait for a while.  Not
only will we accept compilation issues like this one and security
patches, but we will also work on extending features and implementing
new features in line with the current situation.

From: Ozkan Sezer <se...@gm...>
Subject: Re: [Timidity-devel] timidity-devel shout out for main-developer
Date: Tue, 21 Feb 2023 20:40:15 +0300

> My interest is that I'm maintaining libtimidity:
> 
> https://sourceforge.net/projects/libtimidity/
> mirror: https://github.com/sezero/libtimidity
> 
> ... which is a fork from old SDL_sound which in turn had it forked from
> old timidity-0.2i, with additional fixes such as
> https://web.archive.org/web/20170824103526/http://www.onicos.com/staff/iz/timidity/dist/timidity-0.2i-bugfix.pat
> (that onicos.com archive seems have been gone, unfortunately, hence the
> archive.org link) and few additional bits from timidity++. Also applied
> an initial soundfont patch of Takashi Iwai to libtimidity (in soundfont
> branch), but keeping it as devel for now for lack of timidity++ config
> compatibility in it yet.

Ozkan-san, the site above has moved:

http://www33146ue.sakura.ne.jp/staff/iz/timidity/dist/timidity-0.2i-bugfix.pat

Regards,
TAMUKI Shoichi

Re: [Timidity-devel] timidity-devel shout out for main-developer

[Stian S. <sti...@gm...>]

Hi Kenzi Noike (and others on this list)

Thank you for your attempt to reach mister Tamuki. We do not give up yet.
There is also a list of persons in the AUTHORS file we can try to reach out
to.

My ultimate goal is that there should be formed a group of persons that can
maintain a code-base of this project and at a bare minimum accept patches
from sources like linux distroes regarding security and compilation issues.

I would also like this to be a group of persons, so that if a core person
goes "missing", we end up in the current situation we are in now.

Try to redirect distroes etc. to use this maintained code-tree.

The tree mentioned earlier, https://github.com/starg2/timidity41 , seems to
be quite active. I have not checked stability nor how far this has grown
from the original project yet.


Stian Skjelstad


On Wed, Mar 1, 2023 at 1:55 PM Kenzi NOIKE <kn...@gm...> wrote:

> > > First question, are any of the original maintainers still online, and
> if you do not have time, energy or similar. Could you consider to grow the
> size of the group that maintain timidity?
> >
> > I tried to contact Mr. TAMUKI, the recent maintainer via E-mail.
> > I wrote it in his native language Japanese, so maybe there will be any
> response.
>
> Unfortunately, It's been a week, but there was no response from him.
> He may not have read ta...@li...
>
>
> --
> // Kenzi NOIKE
>

Re: [Timidity-devel] timidity-devel shout out for main-developer

[Kenzi N. <kn...@gm...>]

> > First question, are any of the original maintainers still online, and if you do not have time, energy or similiar. Could you consider to grow the size of the group that maintain timidity?
>
> I tried to contact Mr. TAMUKI, the recent maintainer via E-mail.
> I wrote it in his native language Japanese, so maybe there will be any response.

Unfortunately, It's been a week, but there was no response from him.
He may not have read ta...@li...



2023年2月22日(水) 6:57 Kenzi NOIKE <kn...@gm...>:
>
> > First question, are any of the original maintainers still online, and if you do not have time, energy or similiar. Could you consider to grow the size of the group that maintain timidity?
>
> I tried to contact Mr. TAMUKI, the recent maintainer via E-mail.
> I wrote it in his native language Japanese, so maybe there will be any response.
>
>
> > Second question, what is your relation to the Timidity project? I assume there are some kind of relation since you are on this list.
>
> I'm using TiMidity++ with my online converter system "SMF to MP3".
> https://noike.info/~kenzi/cgi-bin/smf2mp3/
>
> My recent interest about TiMidity++ is a fork project "TiMidity++ 41".
> This fork is supported DLS and sfz as SoundFont, experimentary.
> As another feature, it supports use WASAPI for device output.
> https://ja.osdn.net/projects/timidity41/
>
> I want to use sfz in my converter,
> so I'm considering using "TiMidity++ 41" instead of original "TiMidity++".
>
> https://github.com/starg2/timidity41
>
> It was updated a few months ago, so I think this fork project
> "TiMidity++ 41" is alive.
> If you are fixing bugs, make patch or adding new features,
> it may be better to make Pull-Request here.
>
>
>
> 2023年2月22日(水) 3:50 Ozkan Sezer <se...@gm...>:
> >
> > >> They are not actually stripped down, they are, as I said above, just
> > >> forked from the old timidity-0.2i. All three of libtimidity, SDL_sound
> > >> and SDL_mixer share the same code base timidity-wise.  SDL side just
> > >> cannot upgrade to a fork from newer timidity++ code because of its GPL
> > >> license (SDL needs zlib or compatible license.)
> > >
> > > I'd been wondering how libtimidity compared to the main Timidity++
> > > project.  For some reason, I was under the impression it was missing
> > > some features and capabilities of the newer project.  I was looking
> > > into experimenting with the build for Timidity++ and trying to split
> > > it into more of a library with different interfaces at one point so I
> > > could possibly create another front end.  Did not realize libtimidity
> > > had a different license.
> >
> > Tuukka Toivonen had declared that timidity can be used under one of 3
> > licenses, GPL, LGPL and Artistic (the original Artistic at the time):
> > http://ieee.uwaterloo.ca/sca/www.cgs.fi/tt/timidity/
> > https://web.archive.org/web/20180125000438/http://ieee.uwaterloo.ca/sca/www.cgs.fi/tt/timidity/
> >
> > When timidity++ took over, they seem to have favored GPL only (judging
> > that only by the license headers in the sources - haven't discussed it
> > with anyone.)
> >
> > >  That's a really interesting point especially
> > > for use with SDL.  I've seen some libraries with GPL licenses used
> > > with some of the SDL libraries, but that does restrict the license of
> > > a project using both.
> >
> > SDL can dlopen LGPL libraries, that's OK. But it doesn't embed them
> > to avoid viral nature of (L)GPL.
> >
> > > Does anyone know the differences between what features Timidity++
> > > supports and what libtimidity supports?
> >
> > Soundfont support, GS support, as far as I can remember, and further
> > improvements + bug fixes.
> >
> > >  Does libtimidity handle mod file formats
> >
> > Nope - out of its scope and there are other libraries out there with
> > dedicated purpose of mod playback such as libxmp, libmikmod, openmpt,
> > etc.
> >
> > > and work with sf2 soundfonts similar to Timidity++?
> >
> > The soundfont patch I applied in dev branch of libtimidity does work,
> > however unlike timidity++, its timidity.cfg support lack multiple
> > soundfonts support, and also co-existence of GUS patches + soundfonts
> > in the same cfg: That's the reason I still haven't applied to master
> > for release (out of laziness to implement those missing pieces.)
> >
> > --
> > O.S.
> >
> >
> > _______________________________________________
> > Timidity-devel mailing list
> > Tim...@li...
> > https://lists.sourceforge.net/lists/listinfo/timidity-devel
>
>
>
> --
> // Kenzi NOIKE



-- 
// Kenzi NOIKE

Re: [Timidity-devel] timidity-devel shout out for main-developer

[Kenzi N. <kn...@gm...>]

> A few years ago I contributed a patch with --segment feature
> Alas, it is not (yet?) picked by the Linux distributions I use.

https://sourceforge.net/p/timidity/mailman/message/36402700/

That patch was included in Ver. 2.15.0, so it will be reflected when
the package maintainer updates TiMidity++ package for that
distribution you using.



‪2023年2月23日(木) 7:03 ‫Yotam Medini יותם מדיני‬‎ <yot...@gm...>:‬
>
> I use timidity extensively via GNU/Linux command line.
> Mostly as an aid while studying choir parts.
> A few years ago I contributed a patch with --segment feature
> Alas, it is not (yet?) picked by the Linux distributions I use.
> -- yotam
>
> On Tue, Feb 21, 2023 at 5:38 PM Stian Skjelstad <sti...@gm...> wrote:
>>
>> Hello everybody on timidity-devel list
>>
>> This project seems to unfortunatly have gone stale.
>>
>> First question, are any of the original maintainers still online, and if you do not have time, energy or similiar. Could you consider to grow the size of the group that maintain timidity?
>>
>> Second question, what is your relation to the Timidity project? I assume there are some kind of relation since you are on this list.
>>
>>
>>
>> For me, I use Timidity in Open Cubic Player unix version - I maintain a fork of the project since I initially needed to fix some minor issues, and at a later point I needed to make a complete fork since I am preparing my player to be able to hold multiple instances.
>>
>> There is also libtimitidy standalone forks and SDL implementation that are stripped down rewrites and adds support for multiple instances.
>>
>>
>>
>> Best regards
>> Stian Skjelstad
>> _______________________________________________
>> Timidity-devel mailing list
>> Tim...@li...
>> https://lists.sourceforge.net/lists/listinfo/timidity-devel
>
> _______________________________________________
> Timidity-devel mailing list
> Tim...@li...
> https://lists.sourceforge.net/lists/listinfo/timidity-devel



-- 
// Kenzi NOIKE

Re: [Timidity-devel] timidity-devel shout out for main-developer

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

I use timidity extensively via GNU/Linux command line.
Mostly as an aid while studying choir parts.
A few years ago I contributed a patch with --segment feature
<https://sourceforge.net/p/timidity/mailman/message/35180978/>
Alas, it is not (yet?) picked by the Linux distributions I use.
-- yotam

On Tue, Feb 21, 2023 at 5:38 PM Stian Skjelstad <sti...@gm...>
wrote:

> Hello everybody on timidity-devel list
>
> This project seems to unfortunatly have gone stale.
>
> First question, are any of the original maintainers still online, and if
> you do not have time, energy or similiar. Could you consider to grow the
> size of the group that maintain timidity?
>
> Second question, what is your relation to the Timidity project? I assume
> there are some kind of relation since you are on this list.
>
>
>
> For me, I use Timidity in Open Cubic Player unix version - I maintain a
> fork of the project since I initially needed to fix some minor issues, and
> at a later point I needed to make a complete fork since I am preparing my
> player to be able to hold multiple instances.
>
> There is also libtimitidy standalone forks and SDL implementation that are
> stripped down rewrites and adds support for multiple instances.
>
>
>
> Best regards
> Stian Skjelstad
> _______________________________________________
> Timidity-devel mailing list
> Tim...@li...
> https://lists.sourceforge.net/lists/listinfo/timidity-devel
>

Re: [Timidity-devel] timidity-devel shout out for main-developer

[LM <lm...@gm...>]

On Tue, Feb 21, 2023 at 1:50 PM Ozkan Sezer <se...@gm...> wrote:
> The soundfont patch I applied in dev branch of libtimidity does work,
> however unlike timidity++, its timidity.cfg support lack multiple
> soundfonts support, and also co-existence of GUS patches + soundfonts
> in the same cfg: That's the reason I still haven't applied to master
> for release (out of laziness to implement those missing pieces.)

I'll have to check out your soundfont patches.  I've been working with
some of Freepats sf2 files instead of their gus patches, so I'd need
sf2 support for my projects.  FrreePats is mainly using sfz now which
means looking into another switch at some point.  For now most of my
public domain instrument samples are sf2.  I did run across this when
I searched for sf2 and timidity:
https://github.com/ltgcgo/timidity-sf2

Would be nice to see some of the best features of the various
Timidity++ and libtimidity projects and forks combined into one
project someday.

Re: [Timidity-devel] timidity-devel shout out for main-developer

[Kenzi N. <kn...@gm...>]

> First question, are any of the original maintainers still online, and if you do not have time, energy or similiar. Could you consider to grow the size of the group that maintain timidity?

I tried to contact Mr. TAMUKI, the recent maintainer via E-mail.
I wrote it in his native language Japanese, so maybe there will be any response.


> Second question, what is your relation to the Timidity project? I assume there are some kind of relation since you are on this list.

I'm using TiMidity++ with my online converter system "SMF to MP3".
https://noike.info/~kenzi/cgi-bin/smf2mp3/

My recent interest about TiMidity++ is a fork project "TiMidity++ 41".
This fork is supported DLS and sfz as SoundFont, experimentary.
As another feature, it supports use WASAPI for device output.
https://ja.osdn.net/projects/timidity41/

I want to use sfz in my converter,
so I'm considering using "TiMidity++ 41" instead of original "TiMidity++".

https://github.com/starg2/timidity41

It was updated a few months ago, so I think this fork project
"TiMidity++ 41" is alive.
If you are fixing bugs, make patch or adding new features,
it may be better to make Pull-Request here.



2023年2月22日(水) 3:50 Ozkan Sezer <se...@gm...>:
>
> >> They are not actually stripped down, they are, as I said above, just
> >> forked from the old timidity-0.2i. All three of libtimidity, SDL_sound
> >> and SDL_mixer share the same code base timidity-wise.  SDL side just
> >> cannot upgrade to a fork from newer timidity++ code because of its GPL
> >> license (SDL needs zlib or compatible license.)
> >
> > I'd been wondering how libtimidity compared to the main Timidity++
> > project.  For some reason, I was under the impression it was missing
> > some features and capabilities of the newer project.  I was looking
> > into experimenting with the build for Timidity++ and trying to split
> > it into more of a library with different interfaces at one point so I
> > could possibly create another front end.  Did not realize libtimidity
> > had a different license.
>
> Tuukka Toivonen had declared that timidity can be used under one of 3
> licenses, GPL, LGPL and Artistic (the original Artistic at the time):
> http://ieee.uwaterloo.ca/sca/www.cgs.fi/tt/timidity/
> https://web.archive.org/web/20180125000438/http://ieee.uwaterloo.ca/sca/www.cgs.fi/tt/timidity/
>
> When timidity++ took over, they seem to have favored GPL only (judging
> that only by the license headers in the sources - haven't discussed it
> with anyone.)
>
> >  That's a really interesting point especially
> > for use with SDL.  I've seen some libraries with GPL licenses used
> > with some of the SDL libraries, but that does restrict the license of
> > a project using both.
>
> SDL can dlopen LGPL libraries, that's OK. But it doesn't embed them
> to avoid viral nature of (L)GPL.
>
> > Does anyone know the differences between what features Timidity++
> > supports and what libtimidity supports?
>
> Soundfont support, GS support, as far as I can remember, and further
> improvements + bug fixes.
>
> >  Does libtimidity handle mod file formats
>
> Nope - out of its scope and there are other libraries out there with
> dedicated purpose of mod playback such as libxmp, libmikmod, openmpt,
> etc.
>
> > and work with sf2 soundfonts similar to Timidity++?
>
> The soundfont patch I applied in dev branch of libtimidity does work,
> however unlike timidity++, its timidity.cfg support lack multiple
> soundfonts support, and also co-existence of GUS patches + soundfonts
> in the same cfg: That's the reason I still haven't applied to master
> for release (out of laziness to implement those missing pieces.)
>
> --
> O.S.
>
>
> _______________________________________________
> Timidity-devel mailing list
> Tim...@li...
> https://lists.sourceforge.net/lists/listinfo/timidity-devel



-- 
// Kenzi NOIKE

Re: [Timidity-devel] timidity-devel shout out for main-developer

[Ozkan S. <se...@gm...>]

>> They are not actually stripped down, they are, as I said above, just
>> forked from the old timidity-0.2i. All three of libtimidity, SDL_sound
>> and SDL_mixer share the same code base timidity-wise.  SDL side just
>> cannot upgrade to a fork from newer timidity++ code because of its GPL
>> license (SDL needs zlib or compatible license.)
>
> I'd been wondering how libtimidity compared to the main Timidity++
> project.  For some reason, I was under the impression it was missing
> some features and capabilities of the newer project.  I was looking
> into experimenting with the build for Timidity++ and trying to split
> it into more of a library with different interfaces at one point so I
> could possibly create another front end.  Did not realize libtimidity
> had a different license.

Tuukka Toivonen had declared that timidity can be used under one of 3
licenses, GPL, LGPL and Artistic (the original Artistic at the time):
http://ieee.uwaterloo.ca/sca/www.cgs.fi/tt/timidity/
https://web.archive.org/web/20180125000438/http://ieee.uwaterloo.ca/sca/www.cgs.fi/tt/timidity/

When timidity++ took over, they seem to have favored GPL only (judging
that only by the license headers in the sources - haven't discussed it
with anyone.)

>  That's a really interesting point especially
> for use with SDL.  I've seen some libraries with GPL licenses used
> with some of the SDL libraries, but that does restrict the license of
> a project using both.

SDL can dlopen LGPL libraries, that's OK. But it doesn't embed them
to avoid viral nature of (L)GPL.

> Does anyone know the differences between what features Timidity++
> supports and what libtimidity supports?

Soundfont support, GS support, as far as I can remember, and further
improvements + bug fixes.

>  Does libtimidity handle mod file formats

Nope - out of its scope and there are other libraries out there with
dedicated purpose of mod playback such as libxmp, libmikmod, openmpt,
etc.

> and work with sf2 soundfonts similar to Timidity++?

The soundfont patch I applied in dev branch of libtimidity does work,
however unlike timidity++, its timidity.cfg support lack multiple
soundfonts support, and also co-existence of GUS patches + soundfonts
in the same cfg: That's the reason I still haven't applied to master
for release (out of laziness to implement those missing pieces.)

--
O.S.

Re: [Timidity-devel] timidity-devel shout out for main-developer

[LM <lm...@gm...>]

On Tue, Feb 21, 2023 at 12:40 PM Ozkan Sezer <se...@gm...> wrote:
> They are not actually stripped down, they are, as I said above, just
> forked from the old timidity-0.2i. All three of libtimidity, SDL_sound
> and SDL_mixer share the same code base timidity-wise.  SDL side just
> cannot upgrade to a fork from newer timidity++ code because of its GPL
> license (SDL needs zlib or compatible license.)

I'd been wondering how libtimidity compared to the main Timidity++
project.  For some reason, I was under the impression it was missing
some features and capabilities of the newer project.  I was looking
into experimenting with the build for Timidity++ and trying to split
it into more of a library with different interfaces at one point so I
could possibly create another front end.  Did not realize libtimidity
had a different license.  That's a really interesting point especially
for use with SDL.  I've seen some libraries with GPL licenses used
with some of the SDL libraries, but that does restrict the license of
a project using both.

Does anyone know the differences between what features Timidity++
supports and what libtimidity supports?  Does libtimidity handle mod
file formats and work with sf2 soundfonts similar to Timidity++?

Re: [Timidity-devel] timidity-devel shout out for main-developer

[Ozkan S. <se...@gm...>]

> Hello everybody on timidity-devel list
>
> This project seems to unfortunatly have gone stale.

Unfortunately,

> Second question, what is your relation to the Timidity project? I assume
> there are some kind of relation since you are on this list.

My interest is that I'm maintaining libtimidity:

https://sourceforge.net/projects/libtimidity/
mirror: https://github.com/sezero/libtimidity

... which is a fork from old SDL_sound which in turn had it forked from
old timidity-0.2i, with additional fixes such as
https://web.archive.org/web/20170824103526/http://www.onicos.com/staff/iz/timidity/dist/timidity-0.2i-bugfix.pat
(that onicos.com archive seems have been gone, unfortunately, hence the
archive.org link) and few additional bits from timidity++. Also applied
an initial soundfont patch of Takashi Iwai to libtimidity (in soundfont
branch), but keeping it as devel for now for lack of timidity++ config
compatibility in it yet.

> For me, I use Timidity in Open Cubic Player unix version - I maintain a
> fork of the project since I initially needed to fix some minor issues, and
> at a later point I needed to make a complete fork since I am preparing my
> player to be able to hold multiple instances.

Multiple instances like libtimidity support would be good. (Take bits
from it as you like.)

> There is also libtimitidy standalone forks and SDL implementation that
> are stripped down rewrites and adds support for multiple instances.

They are not actually stripped down, they are, as I said above, just
forked from the old timidity-0.2i. All three of libtimidity, SDL_sound
and SDL_mixer share the same code base timidity-wise.  SDL side just
cannot upgrade to a fork from newer timidity++ code because of its GPL
license (SDL needs zlib or compatible license.)

> Best regards
> Stian Skjelstad

--
O.S.

[Timidity-devel] timidity-devel shout out for main-developer

[Stian S. <sti...@gm...>]

Hello everybody on timidity-devel list

This project seems to unfortunatly have gone stale.

First question, are any of the original maintainers still online, and if
you do not have time, energy or similiar. Could you consider to grow the
size of the group that maintain timidity?

Second question, what is your relation to the Timidity project? I assume
there are some kind of relation since you are on this list.



For me, I use Timidity in Open Cubic Player unix version - I maintain a
fork of the project since I initially needed to fix some minor issues, and
at a later point I needed to make a complete fork since I am preparing my
player to be able to hold multiple instances.

There is also libtimitidy standalone forks and SDL implementation that are
stripped down rewrites and adds support for multiple instances.



Best regards
Stian Skjelstad

Re: [Timidity-devel] Patching autoconf fragments for C99 compatibility

[Stian S. <sti...@gm...>]

Hi Jonathan

Could you perhaps make a pull-request so this does not get lost with time?

Stian Skjelstad


On Tue, Jan 31, 2023 at 3:19 PM Jonathan Wakely via Timidity-devel <
tim...@li...> wrote:

> Hi,
>
> In the Fedora project we are fixing packages that rely on obsolete C89
> features like implicit function declarations and implicit int. This
> will be necessary to be able to continue to build the code with future
> compiler releases. For more information, see:
> https://fedoraproject.org/wiki/Toolchain/PortingToModernC
>
> I have attached a patch for TiMidity++ that fixes some problems in
> autoconf fragments. The patch is also attached to:
> https://bugzilla.redhat.com/show_bug.cgi?id=2165930
>
>
>
> _______________________________________________
> Timidity-devel mailing list
> Tim...@li...
> https://lists.sourceforge.net/lists/listinfo/timidity-devel
>

[Timidity-devel] Patching autoconf fragments for C99 compatibility

[Jonathan W. <re...@us...>]

Hi,

In the Fedora project we are fixing packages that rely on obsolete C89
features like implicit function declarations and implicit int. This
will be necessary to be able to continue to build the code with future
compiler releases. For more information, see:
https://fedoraproject.org/wiki/Toolchain/PortingToModernC

I have attached a patch for TiMidity++ that fixes some problems in
autoconf fragments. The patch is also attached to:
https://bugzilla.redhat.com/show_bug.cgi?id=2165930

[Timidity-devel] variable length quantity

[Bob T. <rdt...@gm...>]

Some midi generators use VLQ format. This is apparently
legitimate but timidity produces the error message "Illigal
Variable-length quantity format".

[Timidity-devel] [ANN] TiMidity++ 2.15.0 released

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

Hello all,

At last, we are very glad to announce the official release of
TiMidity++ version 2.15.0.

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

Major changes since 2.14.0:

08/29, 2018
    * Version 2.15.0 released.
    * Add support for segment play option (-G, --segment) with a great
      contribution by Yotam Medini <yot...@gm...>.
    * Add metronome indicator in dumb interface trace mode.
    * Let libao backend set ao options via TIMIDITY_AO_OPTIONS
      environment variable.
    * Fix for CVE-2009-0179, CVE-2009-3996, CVE-2010-2546 and
      CVE-2010-2971.
    * Fix for CVE-2017-11546.
    * Support for Tcl/Tk 8.6.
    * Improve Windows MIDI driver.
    * ...and many other bug fixes.

Regards,
TAMUKI Shoichi

Re: [Timidity-devel] Next release with segment play feature

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

Whenever I install a new version of GNU/Linux distribution
(today LinuxMint=19) I wish next time it will have an official Timidity 
with
the segment feature we have developed.
Any realistic expected release date?
regards -- yotam

On 12/28/2017 03:34 AM, TAMUKI Shoichi wrote:
> Hello all,
>
> From: TAMUKI Shoichi <ta...@li...>
> Subject: Re: [Timidity-devel] Next release with segment play feature
> Date: Sat, 25 Nov 2017 17:38:39 +0900
>
>> Yes, this is a good reason for a release version of TiMidity++.  Also,
>> I plan to commit some fixes to fit with recent software environments.
>> If things go well, we would like to release TiMidity++-2.14.1 on Dec
>> 29th.
> Sorry, it is difficult to release TiMidity++-2.14.1 on December 29th
> because I am busy.  We will postpone the release to the next month.
>
> Regards,
> TAMUKI Shoichi
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Timidity-devel mailing list
> Tim...@li...
> https://lists.sourceforge.net/lists/listinfo/timidity-devel

Re: [Timidity-devel] Next release with segment play feature

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

Hello all,

From: TAMUKI Shoichi <ta...@li...>
Subject: Re: [Timidity-devel] Next release with segment play feature
Date: Sat, 25 Nov 2017 17:38:39 +0900

> Yes, this is a good reason for a release version of TiMidity++.  Also,
> I plan to commit some fixes to fit with recent software environments.
> If things go well, we would like to release TiMidity++-2.14.1 on Dec
> 29th.

Sorry, it is difficult to release TiMidity++-2.14.1 on December 29th
because I am busy.  We will postpone the release to the next month.

Regards,
TAMUKI Shoichi

Re: [Timidity-devel] Next release with segment play feature

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

Hello Yotam,

I'm sorry for the late reply.

From: Yotam Medini <yot...@gm...>
Subject: [Timidity-devel] Next release with segment play feature
Date: Sat, 18 Nov 2017 23:21:04 +0200

> When can we expect the next release of Timidity++ ?
> 
> Specifically, I wish Linux distributions would
> pick a released version having the segment play feature
> implemented by the git-commit below followed by a few
> fixes and improvements.

Yes, this is a good reason for a release version of TiMidity++.  Also,
I plan to commit some fixes to fit with recent software environments.
If things go well, we would like to release TiMidity++-2.14.1 on Dec
29th.

Also, I have not forgotten your request below.

From: Yotam Medini <yot...@gm...>
Subject: [Timidity-devel] segment play - credit
Date: Fri, 24 Jun 2016 21:43:47 +0300

> So far, my contribution is recognized only in
> https://sourceforge.net/p/timidity/git/ci/b129bcae940ecc8f045e16c4676ae92253f910b5/
> with the 'Signed-off-by: ...' git message.
> Could you please have my segment-work mentioned in 
> the ChangeLog as well.

TiMidity++ hourly tarballs are automatically created each time the git
repository has been changed.  ChangeLogs in hourly tarballs are also
automatically generated from the git log.  Currently, "Signed-off-by:"
lines are skipped when generating ChangeLogs, but I plan to improve it
so that author's names will be inserted even in this case.

Regards,
TAMUKI Shoichi

[Timidity-devel] Next release with segment play feature

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

When can we expect the next release of Timidity++ ?

Specifically, I wish Linux distributions would
pick a released version having the segment play feature
implemented by the git-commit below followed by a few
fixes and improvements.

   [b129bc] by  TAMUKI Shoichi
   Add support for segment play option (-G, --segment)
   Play just sub-segment(s) specified by comma separated time segments.
   Each time segment defined by dash separated time values of begin-end.
   Playing from begin to end.
   Signed-off-by: Yotam Medini <yot...@gm...>
   Signed-off-by: TAMUKI Shoichi <ta...@li...>

-- yotam