Yahoo Groups archive
Thread
2003-06-23 by smwither2002
I recorded a pattern at 2 bpm (extreme ambience) and although I repeatedly saved it at that tempo, every time I call it up it's at 4 bpm. Is that the slowest it will save? Not a real impediment, just curious about the limitations of this remarkable machine.
2003-06-23 by steve_the_composer
--- In xl7@yahoogroups.com, "smwither2002" <smwither2002@y...> wrote: > I recorded a pattern at 2 bpm (extreme ambience) and although I > repeatedly saved it at that tempo, every time I call it up it's at 4 > bpm. Is that the slowest it will save? Not a real impediment, just > curious about the limitations of this remarkable machine. 1. To test this on my Command Station, I took a pattern and changed it to 1 bmp. It seemed to work. I then powered down and the 1 bpm setting was gone. 2. I did it again at 274 bpm. After powerdown, it came back as 274. 3. I did it again at 2 bpm. After powerdown, it came back up at 4. I then started aftering files, saving them, and looking at them with E-Loader's midi file listing utility. More to follow. Dr. Steve
2003-06-24 by steve_the_composer
> --- In xl7@yahoogroups.com, "smwither2002" <smwither2002@y...> wrote: > > I recorded a pattern at 2 bpm (extreme ambience) and although I > > repeatedly saved it at that tempo, every time I call it up it's > > at 4 bpm. Is that the slowest it will save? Not a real > > impediment, just curious about the limitations of this > > remarkable machine. > To test this . . . I then started aftering files, saving them, and > looking at them with E-Loader's midi file listing utility. > > More to follow. > > Dr. Steve I am now sorry I tried to figure out what was going on here. I found out much more than anyone probably needs to know. But, since I was checking out the problem, here are my results. A pattern I had saved previously had track 0 data [midi meta events] including tempo as expressed as a usecPerTick. With E-Loader, I was trying to see what was going on with the usecPerTick value at low bpm values. But, unless I'm mistaken, something is up with the way the file is stored and/or saved in OS2.0. I was unable to view this parameter after patterns were resaved. When I downloaded my previously saved pattern to the E-Mu, changed just the name, and uploaded it to the computer, E-Loader no longer displayed the same track 0 data. I also saved an unaltered pattern. That, too, appeared different in E-Loader after being saved. It may be that a change in the file structure in OS2.0 doesn't correspond with how E-Loader1.1 parses the file. So far as I can see the note and other channel data is still in the file. Its just that something about the way the midi track header is stored/viewed seems to be different in OS2.0. Another test I did consisted of starting a track at 4 bpm and editing the conductor track so that at 001.01.002 the tempo would become 1 bpm. The 1 bpm setting stayed with the pattern in memory until powerdown/reboot. Then the 1 bpm became 6 bpm. Who knows why this happens. My guess is that there some sort of mathematical calculation going on with the tempo/usecPerTick variable and during some operations (save/powerdown), the value gets checked or recalculated. This is just a guess. If someone knows, I'd be curious to know what's going on. Based on this, I don't think I will be using such a rate (2 bpm). ======Excerpt # 1 ================================= file name: "P.0.006-Smoover.mid" length: 2972 last modified: Tue Jun 24 00:06:14 EDT 2003 format: 1 numTracks: 17 ppqn: 384 msPerTick: 1.3020833333333333 track 0 start. length: 157 bytes 0: sysex type: 0 length: 72 f0 18 0f 7f 55 01 20 01 04 06 00 02 04 2e 00 03 04 40 00 04 04 00 00 05 04 05 00 06 04 0a 00 07 04 0c 00 08 04 07 00 09 04 00 00 0a 04 00 00 0b 04 00 00 0c 04 0f 00 0d 04 3c 00 0e 04 0a 00 0f 04 05 00 10 04 0a 00 f7 0: seqname: "Smoover #5" 0: smpteoffs: 96:0:0:0.0 0: tempo: 335195 usecPerTick 0: marker: "Main Channel Dests: bbbbbbbbbbbbbbbb" 0: timesig: 4/4 clksPerMetronome: 24 32ndsPerQuarter: 8 12288: endoftrack 0 track 1 start. length: 104 bytes 0: cntrllr ch: 0 ctl: 7 val: 127 0: cntrllr ch: 0 ctl: 10 val: 64 0: cntrllr ch: 0 ctl: 79 val: 0 0: cntrllr ch: 0 ctl: 80 val: 2 0: cntrllr ch: 0 ctl: 0 val: 17 0: cntrllr ch: 0 ctl: 32 val: 0 0: progchg ch: 0 val: 35 0: instname: "MP-7" 0: trackname: "Clav" 1410: noteon ch: 0 key: 46 vel: 120 1522: noteoff ch: 0 key: 46 vel: 0 4482: noteon ch: 0 key: 46 vel: 120 4602: noteoff ch: 0 key: 46 vel: 0 7554: noteon ch: 0 key: 46 vel: 120 7673: noteoff ch: 0 key: 46 vel: 0 10626: noteon ch: 0 key: 46 vel: 127 10738: noteoff ch: 0 key: 46 vel: 0 11265: noteon ch: 0 key: 36 vel: 70 11393: noteon ch: 0 key: 36 vel: 120 11416: noteoff ch: 0 key: 36 vel: 0 11416: noteoff ch: 0 key: 36 vel: 0 11524: noteon ch: 0 key: 36 vel: 111 11712: noteoff ch: 0 key: 36 vel: 0 12288: endoftrack 1 track 2 start. length: 72 bytes === Excerpt # 2 ================================== file name: "P.0.006-Smoover.mid" length: 2956 last modified: Tue Jun 24 00:14:04 EDT 2003 format: 1 numTracks: 17 ppqn: 384 msPerTick: 1.3020833333333333 track 0 start. length: 149 bytes 0: seqname: "Smoover #5 3072: noteoff ch: 7 key: 60 vel: 0 3074: noteon ch: 7 key: 48 vel: 115 3305: noteoff ch: 7 key: 48 vel: 0 3458: noteon ch: 7 key: 51 vel: 106 3682: noteoff ch: 7 key: 51 vel: 0 3842: noteon ch: 7 key: 53 vel: 115 4050: noteoff ch: 7 key: 53 vel: 0 4098: noteon ch: 7 key: 51 vel: 62 4146: noteoff ch: 7 key: 51 vel: 0 4225: noteon ch: 7 key: 55 vel: 115 4417: noteoff ch: 7 key: 55 vel: 0 4487: ptchbnd ch: 7 val: 260 4495: ptchbnd ch: 7 val: 520 4503: ptchbnd ch: 7 val: 780 =============================================
2003-06-24 by Aaron Eppolito
--- steve_the_composer <smw-mail@...> wrote: > I am now sorry I tried to figure out what was going on here. I found > out much more than anyone probably needs to know. But, since I was > checking out the problem, here are my results. Heh, I just checked up on this since Steve went through all this trouble. (bonus points for Steve!) Turns out that it is impossible to store a whole BPM less than 4 in the Standard MIDI File format. For those who *really* want to know more, a tempo event in a standard MIDI file is "FF 51 03 tttttt" where "tttttt" is a 24 bit value denoting microseconds per quarter. The largest this number can be is 16777215 (2^24-1). 60000000/usecPerTick gives you BPM and 60000000/BPM gives you usecPerTick. In the runtime sequencer format, tempo is stored as the much more logical BPM, so until you save it and have to reload it (by selecting another pattern and coming back) it retains the 1-3 BPM. Moral of the story? Don't use BPMs less than 4. Other moral of the story? Make sure the QA guys check saving low BPM tempos. Real moral of the story? Make sure that I check the math the next time I write SMF export code for tempo limits... =) -Aaron __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
2003-06-24 by Andre Lewis
Yes, Yes I care. And I am in awe of the crazy ivestigation and breakdown of superlowtempo (Someone should name an album superlowtempo) by Aaron and Steve! Yikes! Way to go guys! Andre
-----Original Message----- From: Aaron Eppolito [mailto:synthesis77@...] Sent: Monday, June 23, 2003 11:31 PM To: xl7@yahoogroups.com Subject: Re: [xl7] Re: 2 bpm --- steve_the_composer <smw-mail@...> wrote: > I am now sorry I tried to figure out what was going on here. I found > out much more than anyone probably needs to know. But, since I was > checking out the problem, here are my results. Heh, I just checked up on this since Steve went through all this trouble. (bonus points for Steve!) Turns out that it is impossible to store a whole BPM less than 4 in the Standard MIDI File format. For those who *really* want to know more, a tempo event in a standard MIDI file is "FF 51 03 tttttt" where "tttttt" is a 24 bit value denoting microseconds per quarter. The largest this number can be is 16777215 (2^24-1). 60000000/usecPerTick gives you BPM and 60000000/BPM gives you usecPerTick. In the runtime sequencer format, tempo is stored as the much more logical BPM, so until you save it and have to reload it (by selecting another pattern and coming back) it retains the 1-3 BPM. Moral of the story? Don't use BPMs less than 4. Other moral of the story? Make sure the QA guys check saving low BPM tempos. Real moral of the story? Make sure that I check the math the next time I write SMF export code for tempo limits... =) -Aaron __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com To unsubscribe from this group, send an email to: xl7-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
2003-06-24 by erik_magrini@Baxter.com
Real Moral Of The Story? Who needs 4 BPM or less anyway? :) rEalm Moral of the story? Don't use BPMs less than 4. Other moral of the story? Make sure the QA guys check saving low BPM tempos. Real moral of the story? Make sure that I check the math the next time I write SMF export code for tempo limits... =) -Aaron __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com To unsubscribe from this group, send an email to: xl7-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ [Non-text portions of this message have been removed]
2003-06-25 by steve_the_composer
--- In xl7@yahoogroups.com, Aaron Eppolito <synthesis77@y...> wrote: > Heh, I just checked up on this since Steve went through all this > trouble. (bonus points for Steve!)\ Thanks for the follow through (and for the bonus points!). > For those who *really* want to know more, a tempo event in a > standard MIDI file is "FF 51 03 tttttt" where "tttttt" is a 24 bit > value . . . . Now you're talkin' my language! Any idea about what seemed to be a problem with E-Loader interpreting OS2.0 MIDI file data properly? Diagnosing pattern problems is a lot harder using debug! 8-(> Steve