hello all,

i've tried many times to search on this list, but to no avail, about the
detail (i'm sure ive seen discussed..) as to the nature & header (or
lackof?) of the midi file produced by the --midioutfile flag?

i think it's a type 0. but there are lots of apps ive tried that can't read
it however. 

yet when i load it (sucessfully) in Max seq object, & then write it again,
it reads ok in pretty much anything i throw it at.

given therefore that this MIDI "file conversion" i'm performing is now my
final remaining Max dependency - can any one point me to a straight ahead
command line option for working with & doing the necessary conversion /
header writing of the --midioutfile for wider / generic useage?

Like i say, i'm sure this has come up (jpff in particular?), but I have been
unable to locate the info.

would really appreciate as per usual

cheers.

Tim.
-- 
View this message in context: http://www.nabble.com/the---midioutfile-properties-tp14267381p14267381.html
Sent from the Csound - General mailing list archive at Nabble.com.

So I wrote to Tim Thompson (of keykit fame) & said "here's my MIDI file that
Csound generated, & whilst your keykit application is one of the few things
around that seems capable of importing it (but readers, let's just drop that
issue for the time being...one step at a time...) it plays back at
100,000,000 miles an hour - i think it's something to do with the header
data - any ideas?"

he opened my file (with his fancy programming doo-daddery) & advised that
whilst a "normal" midi file might be headed

MFile 0 1 96

the one that Csound made was headed

MFile 0 1 59256

leading him to conclude (quote)

"The 'divisions' value in your header is causing the problem"

I thought this might be due to the fact that i was rendering the MIDI file
from csound as fast as i could / slash in "non real time" - but when i tried
a moment ago rendering the file in "real time" (still using --midioutfile
flag of course) same thing happened. playback with keykit at 50 zillion
BPM...

so is there an issue with the --midioutfile, & can it be resolved, not only
to create a more generic output 'divisions' value, but while who-ever is
looking at it is looking at it, they may as well check all the header data,
because like i say, other apps that i have tried importing the csound
--midioutfile into (Cubase & Ableton both for example... not that i use them
anymore - but desparate times call for desparate measures... ) have failed
to manage to import it

& as i mentioned previously, if i open the file & save it again using the
seq object in Max, the problem "dissapears", so seq obviously creates the
adequate "generic" headers & 'divisions' value, & still produces bog
standard type 0 file formats...

can't believe i've devoted about the last 50 hours of "python / csound" time
to dealing with midi files - conceptually "peripheral" as they are to my
overall creative "direction" here... but u live & learn i guess....

i can still work towards "hand fixing" these midi files for further use
(somehow...), but my whole "batch render MIDI & sco with python" is SO CLOSE
to blockbusting rapid fire fruition here, I really desperately implore those
responsible to fix this issue if at all possible (& i'll shut up about Loris
i promise & try & get that happening using the python environment
instead...well, at least for another 6 months or so anyway ; ) ...)
-- 
View this message in context: http://www.nabble.com/the---midioutfile-properties-tp14267381p14310795.html
Sent from the Csound - General mailing list archive at Nabble.com.

Thanks Oeyvind,

I'm flat out today then off to the cricket! (got free tix)

so i'll follow your sugestion a post some midi generating example code over
the weekend in the hope this can be rectified.

i realise my bug reporting is a little bit "anecdotal" - but to be honest,
that's in part simply to reflect that in essence I don't really know what
the problem is.

as after all, if i did know, then i'd be half way towards fixing it myself!

thanks for the reply & confirming that i am to some lesser degree at least
still sane.


Oeyvind Brandtsegg-2 wrote:
> 
> It looks as if Csound is writing the wrong tempo value to the midi file,
> and
> this should be fixed. It will probably help the developers if you can
> provide a very simple example that writes such a midi file.
> In the meantime, you could work around it by converting the midi file to
> text (using mf2t.exe if you're on windows), and writing a small python
> script that rewrites the tempo value in that text file. I'm sure you can
> automate this procedure to batch process all midi files in a directory, so
> the process could be incorporated in your general setup automatically.
> best
> Oeyvind
> 
> 2007/12/13, Tim Mortimer :
>>
>>
>> So I wrote to Tim Thompson (of keykit fame) & said "here's my MIDI file
>> that
>> Csound generated, & whilst your keykit application is one of the few
>> things
>> around that seems capable of importing it (but readers, let's just drop
>> that
>> issue for the time being...one step at a time...) it plays back at
>> 100,000,000 miles an hour - i think it's something to do with the header
>> data - any ideas?"
>>
>> he opened my file (with his fancy programming doo-daddery) & advised that
>> whilst a "normal" midi file might be headed
>>
>> MFile 0 1 96
>>
>> the one that Csound made was headed
>>
>> MFile 0 1 59256
>>
>> leading him to conclude (quote)
>>
>> "The 'divisions' value in your header is causing the problem"
>>
>> I thought this might be due to the fact that i was rendering the MIDI
>> file
>> from csound as fast as i could / slash in "non real time" - but when i
>> tried
>> a moment ago rendering the file in "real time" (still using --midioutfile
>> flag of course) same thing happened. playback with keykit at 50 zillion
>> BPM...
>>
>> so is there an issue with the --midioutfile, & can it be resolved, not
>> only
>> to create a more generic output 'divisions' value, but while who-ever is
>> looking at it is looking at it, they may as well check all the header
>> data,
>> because like i say, other apps that i have tried importing the csound
>> --midioutfile into (Cubase & Ableton both for example... not that i use
>> them
>> anymore - but desparate times call for desparate measures... ) have
>> failed
>> to manage to import it
>>
>> & as i mentioned previously, if i open the file & save it again using the
>> seq object in Max, the problem "dissapears", so seq obviously creates the
>> adequate "generic" headers & 'divisions' value, & still produces bog
>> standard type 0 file formats...
>>
>> can't believe i've devoted about the last 50 hours of "python / csound"
>> time
>> to dealing with midi files - conceptually "peripheral" as they are to my
>> overall creative "direction" here... but u live & learn i guess....
>>
>> i can still work towards "hand fixing" these midi files for further use
>> (somehow...), but my whole "batch render MIDI & sco with python" is SO
>> CLOSE
>> to blockbusting rapid fire fruition here, I really desperately implore
>> those
>> responsible to fix this issue if at all possible (& i'll shut up about
>> Loris
>> i promise & try & get that happening using the python environment
>> instead...well, at least for another 6 months or so anyway ; ) ...)
>> --
>> View this message in context:
>> http://www.nabble.com/the---midioutfile-properties-tp14267381p14310795.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 

-- 
View this message in context: http://www.nabble.com/the---midioutfile-properties-tp14267381p14326175.html
Sent from the Csound - General mailing list archive at Nabble.com.

Following Oeyvinds advice, here's a brief orc & sco that generates midi.

set a flag --midioutfile=xyz.mid

& get a midifile with unusually hyper-sped up tempo/divisions data, &
possibly other erroneous &/or missing header data (as importation of the
midi file is rejected by many other apps i have tried) - both when
generating a midifile in realtime, & "faster than real time"...

i'm hoping this will be a trivial fix.

thank you.

http://www.nabble.com/file/p14339867/MIDImake.orc MIDImake.orc 

http://www.nabble.com/file/p14339867/Gkeysnperc.sco Gkeysnperc.sco 

http://www.nabble.com/file/p14339867/Gkeysnperc.mid Gkeysnperc.mid 
-- 
View this message in context: http://www.nabble.com/the---midioutfile-properties-tp14267381p14339867.html
Sent from the Csound - General mailing list archive at Nabble.com.

Hi,

I sent this bug report earlier (now quoted below ... cue twilight zone
music) - but nabble seems to be holding it up. maybe it's waiting for
attachments to be checked or something

apologies for any overlap therefore, but i have more info on this issue

i found mf2t.exe & t2mf.exe (thanks Oeyvind) , & what it gives me from the
Csound generated midi file is

Mfile 0 1 -25 120

so i'm deducing this is some sort of alternate header specification

Keykit (& possibly those other programs i have tried unsucessfully to import
to) is looking for a header like

Mfile 0 1 96?

the value i am changing my header to, to get something like normal playback
speed in keykit at 120bpm (& just judging by ear) seems to be around...

Mfile 0 1 1500

so I'm not quite sure what is going on here - but this "alternate
formatting" i think must be close to the heart of the issue?

is this part of the Roland vs the rest of the world historical legacy when
it comes to midi file universal standardisation?

also the "more metric less binary looking" clocks divison (750/1500 vs
960/96) of csound (apparently) vs keykit has me headscratching a bit

But I'm hoping the the 2 "worlds" can be made compatible here in this
instance. I'm ready to mince some MIDI here!




Tim Mortimer wrote:
> 
> Following Oeyvinds advice, here's a brief orc & sco that generates midi.
> 
> set a flag --midioutfile=xyz.mid
> 
> & get a midifile with unusually hyper-sped up tempo/divisions data, &
> possibly other erroneous &/or missing header data (as importation of the
> midi file is rejected by many other apps i have tried) - both when
> generating a midifile in realtime, & "faster than real time"...
> 
> i'm hoping this will be a trivial fix.
> 
> thank you.
> 
>  http://www.nabble.com/file/p14339867/MIDImake.orc MIDImake.orc 
> 
>  http://www.nabble.com/file/p14339867/Gkeysnperc.sco Gkeysnperc.sco 
> 
>  http://www.nabble.com/file/p14339867/Gkeysnperc.mid Gkeysnperc.mid 
> 

-- 
View this message in context: http://www.nabble.com/the---midioutfile-properties-tp14267381p14339899.html
Sent from the Csound - General mailing list archive at Nabble.com.

Dear all,

Tim's post and the responses about aliasing that arises from  
transposing soundfiles up got me thinking. Naturally if you up-sample  
soundfiles prior to transposition and then down-sample them back to  
the original sampling rate aliasing could be eliminated. Is it  
possible to do this in csound using only one csd (I remember reading  
something about UDOs, and that they could use different sampling rate  
from the global sr)? And if so how would one go about it?

Also as far as other transformations (e.g. filtering or fft with  
fsig) are concerned how much of a difference would theoretically  
upsampling make to the sound quality?

Many Thanks in advance
Peiman 

So now (again thanks to Tim Thompson), I understand the Csound midioutfile is
specifying the tempo in SMPTE frames-per-second and ticks-per-frame, not
beat divisions

he's sent me a modified keykit that reads this format - at the moment it
doesn't respond to tempo statements from keykit, but given he's sorted every
other problem pretty much "on the spot", hopefully this is the final hurdle
to cross

given i have had little in the way of compatability with this type of header
with the Csound midi file, i leave it to the developers to determine if a
change in the header specification is desirable or not. This has been a
somewhat long & convoluted "workaround" process (i.e. basically hassling
somebody else into rewriting their program!)





-- 
View this message in context: http://www.nabble.com/the---midioutfile-properties-tp14267381p14357362.html
Sent from the Csound - General mailing list archive at Nabble.com.

If you upsample files, transpose them upwards, then downsample them, you will still 
get aliasing if you don't filter the upsampled version.  The advantage of filtering 
an upsampled version is that you have more flexibility in your filter design, and can 
choose one with a more gradual rolloff, and hence less distortion in the pass-band. 
You'll have more aliasing by doing so, but if you choose your filter correctly that 
*may be* less objectionable than what you would have by not upsampling.  This would 
be dependent on the particular audio you're using, though, and isn't a general solution.

I imagine that it is possible to do this with one csd, but not using UDOs.  UDO's 
allow a higher kr than the rest of the orchestra, but they use the same sr.  The way 
I would implement it is by storing the audio data in a table, upsampling the table, 
performing any necessary processing, then downsampling from the table back into an 
a-variable.  The table would need to be at least as large as  ksmps*upsampling 
factor, e.g. with ksmps=100 and upsampling from 48k to 192k, a factor of 4, the table 
would need to hold 400 samples.  However, you would have to be careful when actually 
processing the data.  You could either implement your processing algorithms manually, 
or possibly use opcodes with a reinit loop (not every opcode would allow this).  I 
don't imagine either being pleasant.

The way upsampling affects the sound quality would to some extent vary depending on 
what you're doing.  With filters, there are simply more options of what you can do if 
you're working near the (old) nyquist limit.  For FFT's, if you multiply your old 
window size by the upsampling factor, you'd get pretty much the same results.

Really, I'd say it's just not worth it.  No matter what you do, you're going to get 
aliasing if you don't filter before you downsample, and even then you'll get some 
aliasing unless you use a near-perfect brick-wall filter or remove audio in the 
audible range.  I would just start at the highest sampling rate I can, and only 
downsample as the last step.

John W. Lato
School of Music
The University of Texas at Austin
1 University Station E3100
Austin, TX 78712-0435
(512) 232-2090

Peiman Khosravi wrote:
> Dear all,
> 
> Tim's post and the responses about aliasing that arises from transposing 
> soundfiles up got me thinking. Naturally if you up-sample soundfiles 
> prior to transposition and then down-sample them back to the original 
> sampling rate aliasing could be eliminated. Is it possible to do this in 
> csound using only one csd (I remember reading something about UDOs, and 
> that they could use different sampling rate from the global sr)? And if 
> so how would one go about it?
> 
> Also as far as other transformations (e.g. filtering or fft with fsig) 
> are concerned how much of a difference would theoretically upsampling 
> make to the sound quality?
> 
> Many Thanks in advance
> Peiman
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound"