You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(8) |
Aug
|
Sep
(8) |
Oct
(6) |
Nov
(27) |
Dec
(5) |
2004 |
Jan
(4) |
Feb
(16) |
Mar
(22) |
Apr
(7) |
May
(5) |
Jun
(4) |
Jul
(20) |
Aug
(8) |
Sep
(8) |
Oct
(12) |
Nov
(19) |
Dec
(7) |
2005 |
Jan
(5) |
Feb
(46) |
Mar
(26) |
Apr
(18) |
May
(10) |
Jun
(22) |
Jul
(8) |
Aug
(3) |
Sep
(32) |
Oct
(9) |
Nov
(19) |
Dec
(7) |
2006 |
Jan
(20) |
Feb
(7) |
Mar
(10) |
Apr
(9) |
May
(23) |
Jun
(6) |
Jul
(6) |
Aug
(8) |
Sep
(7) |
Oct
(3) |
Nov
(8) |
Dec
(25) |
2007 |
Jan
(19) |
Feb
(9) |
Mar
(3) |
Apr
(2) |
May
(5) |
Jun
(6) |
Jul
(3) |
Aug
|
Sep
(3) |
Oct
|
Nov
(8) |
Dec
(1) |
2008 |
Jan
(7) |
Feb
|
Mar
(4) |
Apr
(34) |
May
(12) |
Jun
(1) |
Jul
(23) |
Aug
(6) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2009 |
Jan
(17) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
(6) |
Jul
(30) |
Aug
(15) |
Sep
(7) |
Oct
|
Nov
(1) |
Dec
(7) |
2010 |
Jan
(7) |
Feb
(11) |
Mar
(6) |
Apr
(4) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(4) |
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(12) |
Sep
(3) |
Oct
|
Nov
(1) |
Dec
|
2015 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(22) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(3) |
Nov
|
Dec
(2) |
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2021 |
Jan
|
Feb
(2) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Bob v. d. P. <bo...@me...> - 2015-05-11 22:31:43
|
I don't think this is possible. Notes in MIDI are 4 bit values, and that means a range of 0-127. Only solution I can think of is to split your input into different channels and have, for example, channel 1 for the low stuff and 2 for the upper. That was you, can in theory, get 256 notes. All this depends on the program creating your MIDI. Timidity is NOT the problem :) Hope this helps. On Mon, May 11, 2015 at 1:43 PM, David Bellows <dav...@gm...> wrote: > Hello all, > > I'm using Timidity's tuning table process to implement alternate > tunings. When I have a tuning that divides the octave by more than 12 > notes then I end up losing octave ranges. For example, a 128-EDO would > only have a 1 octave range. A 256-EDO would have a .5 octave range. > > I'm not a programmer so forgive my naivete, but would it be possible > to extend how many notes Timidity can handle and also load larger > tuning tables? For example, to get the full range of the 128-EDO > tuning one would need about 1366 notes (10.6666666 octaves * 128 notes > per octave). > > I'm using this in a program so it's all software based (ie, I'm not > connecting to any instrument) if that helps. > > Thanks, > Dave Bellows > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Timidity-talk mailing list > Tim...@li... > https://lists.sourceforge.net/lists/listinfo/timidity-talk > -- **** Listen to my FREE CD at http://www.mellowood.ca/music/cedars **** Bob van der Poel ** Wynndel, British Columbia, CANADA ** EMAIL: bo...@me... WWW: http://www.mellowood.ca |
From: David B. <dav...@gm...> - 2015-05-11 20:43:44
|
Hello all, I'm using Timidity's tuning table process to implement alternate tunings. When I have a tuning that divides the octave by more than 12 notes then I end up losing octave ranges. For example, a 128-EDO would only have a 1 octave range. A 256-EDO would have a .5 octave range. I'm not a programmer so forgive my naivete, but would it be possible to extend how many notes Timidity can handle and also load larger tuning tables? For example, to get the full range of the 128-EDO tuning one would need about 1366 notes (10.6666666 octaves * 128 notes per octave). I'm using this in a program so it's all software based (ie, I'm not connecting to any instrument) if that helps. Thanks, Dave Bellows |
From: Adrian W. <adr...@gm...> - 2014-11-01 19:17:32
|
Hi, I am looking into integrating timidity into a cross-platform MIDI sequencer. Does anyone have any pointers, and is the documentation available on-line? Thanks Adrian |
From: David B. <dav...@gm...> - 2014-09-29 20:00:42
|
Nevermind. My tuning tables are automatically generated by my software and have lots of information added in as comments. It turns out that in tables for 115 TET and above one of the lines was too long and that was causing the problem. Simple fix on my end. On Fri, Sep 26, 2014 at 5:20 PM, David Bellows <dav...@gm...> wrote: > I should have experimented further first but better late than never. So > using the method outlined in the first email if I extend it to a 114 TET > then it works but at 115 TET (forgive me if my nomenclature is off) > Timidity crashes with the same message as in my previous email. > > On Fri, Sep 26, 2014 at 3:50 PM, David Bellows <dav...@gm...> > wrote: > >> Hello all, >> >> So I've been experimenting with alternate tunings and I created what I >> think would be called a 128 TET. I've created a tuning table for it and >> when I attempt to use it in Timidity to play a MIDI file like so: >> >> timidity --freq-table=tuning_table.tbl music.midi >> >> I get the following error: >> >> Requested buffer size 32768, fragment size 8192 >> ALSA pcm 'default' set buffer size 32768, period size 8192 bytes >> Playing Piano_Standard_Notation.midi >> MIDI file: Piano_Standard_Notation.midi >> Format: 0 Tracks: 1 Divisions: 1000 >> Invalid sample increment a=0.000000e+00 32000 2 36708 44100 >> Aborted (core dumped) >> >> I then created what I think would be called a 64 TET and when using the >> exact same command (with the updated tuning table) it plays just fine. The >> tuning tables are created automatically by my software but there is >> certainly a chance I screwed that up somewhere. The 128 TET uses the form: >> 2^(1/128),2^(2/128),...,2^(128/128) whereas the 64 TET uses >> 2^(1/64)...2^(64/64) >> >> If there's some Timidity setting that would help that would be great but >> any help would be appreciated. >> >> Thanks, >> Dave Bellows >> > > |
From: David B. <dav...@gm...> - 2014-09-27 00:20:30
|
I should have experimented further first but better late than never. So using the method outlined in the first email if I extend it to a 114 TET then it works but at 115 TET (forgive me if my nomenclature is off) Timidity crashes with the same message as in my previous email. On Fri, Sep 26, 2014 at 3:50 PM, David Bellows <dav...@gm...> wrote: > Hello all, > > So I've been experimenting with alternate tunings and I created what I > think would be called a 128 TET. I've created a tuning table for it and > when I attempt to use it in Timidity to play a MIDI file like so: > > timidity --freq-table=tuning_table.tbl music.midi > > I get the following error: > > Requested buffer size 32768, fragment size 8192 > ALSA pcm 'default' set buffer size 32768, period size 8192 bytes > Playing Piano_Standard_Notation.midi > MIDI file: Piano_Standard_Notation.midi > Format: 0 Tracks: 1 Divisions: 1000 > Invalid sample increment a=0.000000e+00 32000 2 36708 44100 > Aborted (core dumped) > > I then created what I think would be called a 64 TET and when using the > exact same command (with the updated tuning table) it plays just fine. The > tuning tables are created automatically by my software but there is > certainly a chance I screwed that up somewhere. The 128 TET uses the form: > 2^(1/128),2^(2/128),...,2^(128/128) whereas the 64 TET uses > 2^(1/64)...2^(64/64) > > If there's some Timidity setting that would help that would be great but > any help would be appreciated. > > Thanks, > Dave Bellows > |
From: David B. <dav...@gm...> - 2014-09-26 22:50:41
|
Hello all, So I've been experimenting with alternate tunings and I created what I think would be called a 128 TET. I've created a tuning table for it and when I attempt to use it in Timidity to play a MIDI file like so: timidity --freq-table=tuning_table.tbl music.midi I get the following error: Requested buffer size 32768, fragment size 8192 ALSA pcm 'default' set buffer size 32768, period size 8192 bytes Playing Piano_Standard_Notation.midi MIDI file: Piano_Standard_Notation.midi Format: 0 Tracks: 1 Divisions: 1000 Invalid sample increment a=0.000000e+00 32000 2 36708 44100 Aborted (core dumped) I then created what I think would be called a 64 TET and when using the exact same command (with the updated tuning table) it plays just fine. The tuning tables are created automatically by my software but there is certainly a chance I screwed that up somewhere. The 128 TET uses the form: 2^(1/128),2^(2/128),...,2^(128/128) whereas the 64 TET uses 2^(1/64)...2^(64/64) If there's some Timidity setting that would help that would be great but any help would be appreciated. Thanks, Dave Bellows |
From: Bill C. <bil...@ou...> - 2014-08-27 08:30:48
|
Hello, Thanks for your response. > Perhaps, how about "-B2,8 -s48000 -Os -iAD" options? Setting the daemon sample rate to 48kHz doesn't change anything. > Or try out commentting out period_size and buffer_size in /etc/asound.conf. Indeed, if I comment out all the extra settings (period size, buffer size and resampling frequency) in the alsa config, the daemon plays everything as should (no jitter, no stuttering). But I don't really see why those should affect timidity? How exactly does resampling the dmixer output affect timidity's timing? Oh well, I guess I'll have to learn to live with it. I do want to express my sincere appreciation for your assistance! Kind regards, Bill Carson |
From: TAMUKI S. <ta...@li...> - 2014-08-27 00:09:24
|
Hello, Sorry, I am not able to reproduce the jitter with "-B2,8" option on my environment. From: Bill Carson <bil...@ou...> Subject: Re: [timidity-talk] Out of sync playback with ALSA sequencer on Debian Date: Mon, 25 Aug 2014 13:07:53 +0200 > I resample everything to 48kHz by default, as for some reason 44.1 > sounds really distorted on my integrated DAC. Could that have > something to do with it? Perhaps, how about "-B2,8 -s48000 -Os -iAD" options? Or try out commentting out period_size and buffer_size in /etc/asound.conf. Regards, TAMUKI Shoichi |
From: Bill C. <bil...@ou...> - 2014-08-25 11:08:01
|
Hello, Thanks for your prompt response! > Perhaps, TiMidity++ ALSA sequencer interface has been running as a > system service (like this: timidity -Os -iA) on Debian Wheezy/Jessy. The default timidity-daemon that is run by debian has the following parameters: -B2,8 -Os -iAD > Please try out adding "-B2,8 -q0/0" options. The fragment size is > adjustable. The smaller number gives better real-time response. > Adding "-B2,9" might be a good idea. If I run the daemon with the parameters you've given: $ timidity -iA -B2,9 -q0/0 -Os --sequencer-ports=1 -EFresamp=1 Requested buffer size 4096, fragment size 2048 ALSA pcm 'default' set buffer size 30104, period size 15052 bytes TiMidity starting in ALSA server mode Opening sequencer port: 129:0 Requested buffer size 4096, fragment size 2048 ALSA pcm 'default' set buffer size 30104, period size 15052 bytes $ aplaymidi -p 129:0 filename.mid There's still jitter. Even setting the number of fragments to 'maximum' (or minimum) (-B0) doesn't seem to have any effect. I've played around with the audio buffer size (-q) as well. Setting a smaller buffer seems to make it somewhat better, but still not as it should be. However, I've noticed that my /etc/asound.conf might have something to do with it. I have the following set there: pcm.dmixer { type dmix ipc_key 2 #unique IPC key ipc_key_add_uid TRUE slave { pcm "hw:Intel" #period_time 0 #in useconds period_size 4096 #in bytes buffer_size 131072 #in bytes rate 48000 format S32_LE } bindings { 0 0 1 1 } hint { show on description "Default sink for multiple (resampled) streams." } } I resample everything to 48kHz by default, as for some reason 44.1 sounds really distorted on my integrated DAC. Could that have something to do with it? Kind regards, Bill Carson |
From: TAMUKI S. <ta...@li...> - 2014-08-25 01:53:32
|
Hello, From: Bill Carson <bil...@ou...> Subject: [timidity-talk] Out of sync playback with ALSA sequencer on Debian Date: Sun, 24 Aug 2014 12:29:01 +0200 > If I play the files without using the ALSA server: > > timidity -Os filename.mid > > the playback is fine. If I play the files with the ALSA server: > > aplaymidi -p 128:0 filename.mid > > there is a lot of jitter and the notes are out of sync. This happens > both with aplaymidi as with other applications (e.g. games running in > dosbox and wine). Perhaps, TiMidity++ ALSA sequencer interface has been running as a system service (like this: timidity -Os -iA) on Debian Wheezy/Jessy. Please try out adding "-B2,8 -q0/0" options. The fragment size is adjustable. The smaller number gives better real-time response. Adding "-B2,9" might be a good idea. $ timidity -iA -B2,9 -q0/0 --sequencer-ports=1 -EFresamp=1 & ... Requested buffer size 4096, fragment size 2048 ALSA pcm 'default' set buffer size 4096, period size 1364 bytes TiMidity starting in ALSA server mode Opening sequencer port: 128:0 $ aplaymidi -p 128:0 filename.mid Regards, TAMUKI Shoichi |
From: Bill C. <bil...@ou...> - 2014-08-24 10:29:09
|
Hi, First of all I would like to thank you guys for creating this great piece of software, and handing it out for free! However, I have issues with playing back midi files with TiMidity++ on Debian Wheezy/Jessy. If I play the files without using the ALSA server: timidity -Os filename.mid the playback is fine. If I play the files with the ALSA server: aplaymidi -p 128:0 filename.mid there is a lot of jitter and the notes are out of sync. This happens both with aplaymidi as with other applications (e.g. games running in dosbox and wine). I've tried to resolve the problem myself, without success: - I tried different soundfonts (both the default one and external ones) - I tried to lower the sampling frequency (which is noticeable in quality, but the jitter is still present) - I tried all available ports - The Arch wiki says that running TiMidity++ with the libao backend may solve such issues, but this backend is not compiled in the binaries of the debian repos. I therefore compiled timidity myself with this backend. The sound is not out of sync this time, but it stutters :( With the libao "verbose" option, I get these warnings: “ao_alsa debug: underrun, restarting...” (changing the buffer_time value does not help) If I change the backend of the TiMidity++ server to "output to file" (option -Ow), the resulting file does not contain any jitter or stuttering at all. Clearly there must be something wrong with the ALSA backend, but where should I look? (I don't use Pulse, as TiMidity++ has no native PulseAudio support) To illustrate the problem, I recorded samples with the snd_aloop loopback module: - Playback to file, as it should sound ( -Ow ): http://a.pomf.se/iawwsh.mp3 - Playback to alsa sequencer with alsa, out of sync ( -Os ): http://a.pomf.se/lbtdpu.mp3 - Playback to alsa sequencer with libao, stuttering ( -OO ): http://a.pomf.se/djbipx.mp3 I am really desperate at this point: any hints would be welcome! Kind regards, Bill Carson |
From: Peter B. <pj...@pj...> - 2014-08-08 10:13:53
|
Yair K. wrote: > > --preserve-silence > Oh, right, that's in 2.14.0. 2.13.2 didn't have this. You can get > the patch from the list and apply it, or build that version yourself. Sorry, our emails crossed; you got to the answer before I got to the question. Thanks, Peter Billam http://www.pjb.com.au pj...@pj... (03) 6278 9410 "Follow the charge, not the particle." -- Richard Feynman from The Theory of Positrons, Physical Review, 1949 |
From: Peter B. <pj...@pj...> - 2014-08-08 10:10:25
|
Yair K. wrote: > There's an option for this: > --preserve-silence > Do not drop initial silence. Default: drop initial silence That's exactly what's needed :-) Unfortunately, --preserve-silence is not recognised in my TiMidity++ version 2.13.2 (debian stable). Is it known when --preserve-silence was introduced ? Regards, Peter Billam P.S. In the meantime, I have a work-around in place and working; on a channel (sync_cha) not present in the t_cha5.mid I add {'control_change', 1, sync_cha, 7, 0} -- Channel Volume = 0 {'note', 2, 1, sync_cha, 7, 1} -- Note Velocity = 1 right at the beginning, after the 'set_tempo'. (ref: http://www.pjb.com.au/comp/lua/MIDI.html#events ) Thanks for your help. http://www.pjb.com.au pj...@pj... (03) 6278 9410 "Follow the charge, not the particle." -- Richard Feynman from The Theory of Positrons, Physical Review, 1949 |
From: Yair K. <ce...@gm...> - 2014-08-08 09:59:57
|
<html style="direction: ltr;"> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style> </head> <body style="direction: ltr;" bidimailui-detected-decoding-type="latin-charset" bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 08/08/2014 12:50 PM, Yair K. wrote:<br> </div> <blockquote cite="mid:53E...@gm..." type="cite"> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; }</style>There's an option for this:<br> <br> --preserve-silence<br> Do not drop initial silence. Default: drop initial silence<br> <br> </blockquote> <br> Oh, right, that's in 2.14.0. 2.13.2 didn't have this. You can get the patch from the list and apply it, or build that version yourself.<br> </body> </html> |
From: Yair K. <ce...@gm...> - 2014-08-08 09:48:15
|
<html style="direction: ltr;"> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style> </head> <body style="direction: ltr;" bidimailui-detected-decoding-type="latin-charset" bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 08/08/2014 05:40 AM, Peter Billam wrote:<br> </div> <blockquote cite="mid:3a2b83$sn...@ip..." type="cite"> <pre wrap="">Greetings all, I'm trying to split a .mid file t.mid into separate channels eg t_cha0.mid t_cha1.mid t_cha4.mid then convert each of those to wav t_cha0.wav t_cha1.wav t_cha4.wav so that I can treat them with effects eg using sox then mix them back together eg using ecasound. BUT when I convert mid->wav using timidity, eg: timidity -Ow -o t_cha1.wav t_cha1.mid the four seconds of initial silence in t_cha1.mid before the first note gets suppressed :-( thus destroying the co-ordination between my files and making mixdown impossible :-( I've been through man timidity and man timidity.cfg and there are hundreds of options, but I see nothing to disable the destruction of the initial silence. I tried inserting a note_off event into t_cha1.mid just before the 4-second initial silence, but timidity is 'clever' enough to ingore it :-( Does anyone know a timidity option to preserve initial silence ? I'm on debian stable ... TiMidity++ version 2.13.2 Regards, Peter Billam <a class="moz-txt-link-freetext" href="http://www.pjb.com.au">http://www.pjb.com.au</a> <a class="moz-txt-link-abbreviated" href="mailto:pj...@pj...">pj...@pj...</a> (03) 6278 9410 "Follow the charge, not the particle." -- Richard Feynman from The Theory of Positrons, Physical Review, 1949 ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/bds">http://p.sf.net/sfu/bds</a> _______________________________________________ Timidity-talk mailing list <a class="moz-txt-link-abbreviated" href="mailto:Tim...@li...">Tim...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/timidity-talk">https://lists.sourceforge.net/lists/listinfo/timidity-talk</a> </pre> </blockquote> <br> There's an option for this:<br> <br> --preserve-silence<br> Do not drop initial silence. Default: drop initial silence<br> <br> </body> </html> |
From: TAMUKI S. <ta...@li...> - 2014-08-08 05:59:38
|
Hello, From: "Peter Billam" <pj...@pj...> Subject: [timidity-talk] timidity destroys initial silence :-( Date: Fri, 8 Aug 2014 12:40 +1000 > I'm trying to split a .mid file t.mid into separate channels > eg t_cha0.mid t_cha1.mid t_cha4.mid > then convert each of those to wav t_cha0.wav t_cha1.wav t_cha4.wav > so that I can treat them with effects eg using sox > then mix them back together eg using ecasound. First, you do not have to split a midi file into separate channels. You can convert each of those to wave files using -Q option. > BUT when I convert mid->wav using timidity, eg: > timidity -Ow -o t_cha1.wav t_cha1.mid > the four seconds of initial silence in t_cha1.mid before the first > note gets suppressed :-( thus destroying the co-ordination between > my files and making mixdown impossible :-( > > I've been through man timidity and man timidity.cfg > and there are hundreds of options, but I see nothing to > disable the destruction of the initial silence. > > I tried inserting a note_off event into t_cha1.mid just before > the 4-second initial silence, but timidity is 'clever' enough to > ingore it :-( > > Does anyone know a timidity option to preserve initial silence ? To avoid skipping initial silence, you can try to add a dummy track which contains only one midi note on and off event at offset zero. Here is the sample script. In this case, the dummy track is assigned to channel 32, which is not used. ---------------------------------------------------------------------- #!/bin/sh # add a dummy track mf2t -ntv kkr8p.mid kkr8p.txt cp -p kkr8p.txt kkr8p_dummy.txt sed -i '/^MFile/s/22/23/' kkr8p_dummy.txt cat <<- "EOF" >> kkr8p_dummy.txt MTrk 0:-1:0 Meta TrkName "" 0:-1:0 Meta 0x21 01 2:-1:-2 On ch=16 note=c5 vol=64 2:0:-2 On ch=16 note=c5 vol=0 TrkEnd EOF t2mf kkr8p_dummy.txt kkr8p_dummy.mid # make wav (melody) timidity -idt -Q0,-1,-5,-11,-12,-17,-20 -Ow -o kkr8p1.wav kkr8p_dummy.mid # make wav (harmony) timidity -idt -Q1,5,9,10,11,12,17,20,32 -Ow -o kkr8p2.wav kkr8p_dummy.mid # make wav (percussion) timidity -idt -Q0,-9,-10,-32 -Ow -o kkr8p3.wav kkr8p_dummy.mid # mix them sox -m kkr8p1.wav kkr8p2.wav kkr8p3.wav kkr8p.wav ---------------------------------------------------------------------- Regards, TAMUKI Shoichi |
From: Bob v. d. P. <bo...@me...> - 2014-08-08 03:34:04
|
Not what you want to hear ... but I don't think so. In my program MMA I have added a "sync" option just for this reason. It creates a short (one midi tick) on and then off event at offset 0. I think this is the only way to do this. On Thu, Aug 7, 2014 at 7:40 PM, Peter Billam <pj...@pj...> wrote: > Greetings all, > > I'm trying to split a .mid file t.mid into separate channels > eg t_cha0.mid t_cha1.mid t_cha4.mid > then convert each of those to wav t_cha0.wav t_cha1.wav t_cha4.wav > so that I can treat them with effects eg using sox > then mix them back together eg using ecasound. > > BUT when I convert mid->wav using timidity, eg: > timidity -Ow -o t_cha1.wav t_cha1.mid > the four seconds of initial silence in t_cha1.mid before the first > note gets suppressed :-( thus destroying the co-ordination between > my files and making mixdown impossible :-( > > I've been through man timidity and man timidity.cfg > and there are hundreds of options, but I see nothing to > disable the destruction of the initial silence. > > I tried inserting a note_off event into t_cha1.mid just before > the 4-second initial silence, but timidity is 'clever' enough to > ingore it :-( > > Does anyone know a timidity option to preserve initial silence ? > > I'm on debian stable ... > TiMidity++ version 2.13.2 > > Regards, Peter Billam > > http://www.pjb.com.au pj...@pj... (03) 6278 9410 > "Follow the charge, not the particle." -- Richard Feynman > from The Theory of Positrons, Physical Review, 1949 > > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Timidity-talk mailing list > Tim...@li... > https://lists.sourceforge.net/lists/listinfo/timidity-talk > -- **** Listen to my FREE CD at http://www.mellowood.ca/music/cedars **** Bob van der Poel ** Wynndel, British Columbia, CANADA ** EMAIL: bo...@me... WWW: http://www.mellowood.ca |
From: Peter B. <pj...@pj...> - 2014-08-08 02:56:00
|
Greetings all, I'm trying to split a .mid file t.mid into separate channels eg t_cha0.mid t_cha1.mid t_cha4.mid then convert each of those to wav t_cha0.wav t_cha1.wav t_cha4.wav so that I can treat them with effects eg using sox then mix them back together eg using ecasound. BUT when I convert mid->wav using timidity, eg: timidity -Ow -o t_cha1.wav t_cha1.mid the four seconds of initial silence in t_cha1.mid before the first note gets suppressed :-( thus destroying the co-ordination between my files and making mixdown impossible :-( I've been through man timidity and man timidity.cfg and there are hundreds of options, but I see nothing to disable the destruction of the initial silence. I tried inserting a note_off event into t_cha1.mid just before the 4-second initial silence, but timidity is 'clever' enough to ingore it :-( Does anyone know a timidity option to preserve initial silence ? I'm on debian stable ... TiMidity++ version 2.13.2 Regards, Peter Billam http://www.pjb.com.au pj...@pj... (03) 6278 9410 "Follow the charge, not the particle." -- Richard Feynman from The Theory of Positrons, Physical Review, 1949 |
From: TAMUKI S. <ta...@li...> - 2012-06-29 00:19:59
|
Hello all, At last, we are very glad to announce the official release of TiMidity++ version 2.14.0. http://sourceforge.net/projects/timidity/files/TiMidity++/TiMidity++-2.14.0/ Major changes since 2.13.2: 06/29, 2012 * Version 2.14.0 released. * Add --reverb option for Freeverb parameter. * Add --preserve-silence option. * Add a "trysource" config file directive, which allows to try and source other config files, while continuing without error if the specified file is missing. * Support for GM2 Master Fine/Coarse Tuning, GS Master Tune and XG Master Tuning (4C not 27) SysEx. * Allow Device Numbers other than 0x10 for XG SYSTEM ON SYSEX events. * Fix multiple vulnerabilities found in GNU gzip also apply to lha, namely: CVE-2006-4335, CVE-2006-4337 and CVE-2006-4338. * Support for lzma decompression. * Support for ipv6. * Support for libpng 1.5 and newer. * Support for Tcl/Tk 8.5. * Make compatible with xaw3d v1.5, style changes. * Various improvements in XAW interface (see README.xaw). * Support for Windows Named Pipe interface. * ...and many other bug fixes. Regards, TAMUKI Shoichi |
From: A. Z. <and...@co...> - 2011-12-06 15:04:56
|
On Tue, 6 Dec 2011 15:22:17 +0800 (CST) 中天 吾 <tt...@ki...> wrote: > > It's a good alternative, but not the best, because the wav file > takes much more space than midi file. > You could write a Windows batch script that would delete the wav file after converting and playing. The script would need to be passed the start and end times as parameters. So let's say this script is called "play_midi." It would be used in this way: play_midi midifile.mid 00:XX:XX 00:YY:YY This approach would be only a little more complicated than invoking TiMidity++ itself from the command line. You could either use the traditional batch script (.bat files) or the newer PowerShell script to accomplish this, and you will need to find a Windows audio player that can be invoked from the command line. |
From: 中天 吾 <tt...@ki...> - 2011-12-06 07:36:12
|
Dear Zimmer, Thanks for your reply. Piotrek also suggested me this way. It's a good alternative, but not the best, because the wav file takes much more space than midi file. Timidity++ package also provides "timw32g.exe" which is the GUI version of Timidity. I can use the mouse to drag its scroll bar and adjust the playing time. Therefore, there should some way to do the same thing from the command line. I think one can rewrite the source code of Timidity to do this function. However, I'm not familiar with the software structure of Timidity. It's too difficult for me to rewrite the source code of Timidity. Could you please give me any suggestion? Thanks. Sincerely, Tony ________________________________ 寄件者: A. Zimmer <and...@co...> 收件者: tim...@li... 副本: 中天 吾 <tt...@ki...> 寄件日期: 2011/12/6 (週二) 6:52 AM 主旨: Re: [timidity-talk] How to modify the playing duration from the command line On Fri, 2 Dec 2011 21:58:26 +0800 (CST) 中天 吾 <tt...@ki...> wrote: > > Does anyone know how to modify the playing duration of timidity++ from > the command line? > A way do do this would be to first use TiMidity++ to output a wav file and then use a competent audio player to limit playback to the specified time interval. |
From: A. Z. <and...@co...> - 2011-12-05 22:52:55
|
On Fri, 2 Dec 2011 21:58:26 +0800 (CST) 中天 吾 <tt...@ki...> wrote: > > Does anyone know how to modify the playing duration of timidity++ from > the command line? > A way do do this would be to first use TiMidity++ to output a wav file and then use a competent audio player to limit playback to the specified time interval. |
From: 中天 吾 <tt...@ki...> - 2011-12-02 14:11:49
|
Dear all, Does anyone know how to modify the playing duration of timidity++ from the command line? I wonder that whether timidity++ provides this function. If I type "timidity.exe xx.mid" in the command line, timidity will play xx.mid from the 0 second. Is it possible to play a midi from some time to another time, like from 10 second to 30 second by adding some parameters in the command line? I've check the help of timidity++; however, I cannot find any parameter can do this. Does anyone give some hints?Thanks. PS: my platform is windows XP. Sincerely, Tony |
From: TAMUKI S. <ta...@li...> - 2011-10-28 08:43:40
|
Hello, From: Freeman Gilmore <fre...@gm...> Subject: [timidity-talk] midi trunning Date: Fri, 28 Oct 2011 04:06:05 -0400 > Does timidity++ comply to the midi tuning standard in real time? Yes. Regards, TAMUKI Shoichi |
From: Freeman G. <fre...@gm...> - 2011-10-28 08:06:12
|
Does timidity++ comply to the midi tuning standard in real time? Thank you, ƒree |