[FFmpeg-devel-irc] IRC log for 2010-05-08

[irc at mansr.com]

[11:26:12] <BastyCDGS> greetz to all
[11:26:17] <BastyCDGS> have good news
[11:26:25] <BastyCDGS> no need for reverse engineering dctv IFF-ANIM
[11:26:31] <BastyCDGS> found the specs for it in IFF-DEEP
[11:27:03] <BastyCDGS> it's called tvdc there but I'm pretty sure it's the same ;)
[11:27:51] <iive> \o/
[11:28:33] <mru> forgive if I'm not quite so excited
[11:28:36] <mru> *me
[11:29:22] <BastyCDGS> I would wonder anyway, as you aren't an amiga user and have probably not much usage for such stuff ;)
[11:29:50] <mru> indeed, never had an amiga
[11:29:55] <mru> never "got it"
[11:30:40] <BastyCDGS> as I dunno of any law which forces you to have one, it should be fine ;)
[11:31:15] <Compn> BastyCDGS : find the specs to vivo :)
[11:33:25] <BastyCDGS> what's the problem with vivo?
[11:35:26] <mru> vivo used to be a cheap swedish supermarket
[11:35:50] <mru> got bought out by lidl or something
[11:36:19] <Compn> vivo uses some non standard h263 which ffmpeg bails on iirc
[11:37:38] <Compn> not to mention, porting the demuxer from mplayer
[11:39:27] <BastyCDGS> you mean those with fourcc viv2?
[11:43:46] <Kovensky> hm, shouldn't all codecs return decoded audio in the SMPTE channel order?
[11:46:54] <BastyCDGS> btw, I found a copy of old DeluxePaint2 for DOS
[11:46:55] <BastyCDGS> http://iaedq.tripod.com/
[11:47:00] <BastyCDGS> it creates IFF-PBM files
[11:47:08] <BastyCDGS> should be good for testing ;)
[11:47:42] <Kovensky> lol
[11:55:25] <Kovensky> nvm @ previous question, I should read specs more
[11:56:17] <BastyCDGS> hi jai :)
[11:56:33] <BastyCDGS> have good news, I found the dctv anim specs in the IFF-DEEP stuff
[11:56:44] <BastyCDGS> they're called tvdc here
[12:12:48] <jai> hello BastyCDGS
[12:12:56] <BastyCDGS> how are u?
[12:17:27] <BastyCDGS> can someone tell what's the remaining problem with the heavy-opt-dp8 patch?
[12:55:20] <thresh> OT: anyone tried vdpau on ion-based eeepc 1201n?
[12:55:36] <twnqx> no, only on acer revo :X
[14:14:46] <tiger108> hello there, i would need some support to install and configure qt-faststart, any one can help me???
[14:16:54] <tiger108> ???
[14:19:00] <tiger108> anyone?
[14:41:52] <BastyCDGS> hey saste :)
[14:41:56] <BastyCDGS> how are u?
[16:01:39] <BastyCDGS> yeah
[16:01:44] <BastyCDGS> peter sent me a IFF PBM raw
[16:02:55] <BastyCDGS> and my latest HAM changes work with it ;)
[16:10:57] <pJok> BastyCDGS, i haven't seen anyone working so furriously at something as you :)
[16:11:28] <BastyCDGS> just want get it fine ;)
[16:20:02] <_av500_> pJok: he needs to be fast before the last amiga decays forever..
[16:20:27] <BastyCDGS> av500, there's still UAE ;)
[16:20:40] <BastyCDGS> even the C64 didn't die out totally yet
[16:21:08] * twnqx still has two of them
[16:21:12] <twnqx> sadly, no ffmpeg on them.
[16:21:19] <BastyCDGS> ??
[16:21:24] <BastyCDGS> ffmpeg works fine on amiga
[16:21:27] <twnqx> on the c64s
[16:21:30] <BastyCDGS> ami_stuff uses ffmpeg on amiga
[16:21:33] <BastyCDGS> oh ok
[16:23:33] <BastyCDGS> av500, apart from this IFF ILBM can also be created by popular PC software
[16:23:44] <BastyCDGS> dpaint2e adobe photoshop, etc.
[16:24:01] <BastyCDGS> although photoshop has a bug writing IFF ILBM files in the byterun1 encoder
[16:24:14] <BastyCDGS> it doesn't handle byterun1 byte -128 as nop
[16:24:31] <BastyCDGS> btw, what's the best way to handle such stuff in ffmpeg?
[16:24:37] <BastyCDGS> should I provide some config stuff?
[16:24:53] <BastyCDGS> like byterun1=nop?
[16:25:22] <CIA-7> ffmpeg: reimar * r23057 /trunk/libavcodec/avcodec.h: Another try for fixing/improving decode_video documentation.
[16:32:54] <CIA-7> ffmpeg: reimar * r23058 /trunk/configure:
[16:32:54] <CIA-7> ffmpeg: Remove hardcoded-tables hack for IA-64: with latest binutils that now actually
[16:32:54] <CIA-7> ffmpeg: causes linking errors instead of avoiding them.
[16:34:04] <pJok> twnqx, 8bit ffmpeg?
[16:34:13] <twnqx> :>
[16:34:32] <BastyCDGS> patch is welcome ;)
[16:34:47] * mru has a long-term plan to put ffmpeg on C64x though
[16:34:55] <mru> that's a TI DSP
[16:35:11] <_av500_> after DNF?
[16:35:19] <mru> no, week before
[16:35:31] <BastyCDGS> DNF?
[16:36:24] <BastyCDGS> hi BBB :)
[16:36:28] <BBB> hola
[16:36:32] <BBB> good set of patches you got there
[16:36:45] <pJok> mru, TI DSP isn't a bad idea... but doesn't that mean that you'd have to code instead of troll? ;)
[16:36:46] <BBB> it's a jungle again, I didn't pay attention for a few days and completely lost track :)
[16:36:54] <BastyCDGS> yeah and I just got an IFF-PBM raw encoded
[16:37:00] <BastyCDGS> so I could just test my HAM changes with it
[16:37:04] <BastyCDGS> and it works like a charm ;)
[16:37:10] <BastyCDGS> peter replied today
[16:37:28] <mru> pJok: nobody pays me to troll
[16:37:57] * BastyCDGS hastly revokes payment to mru *gg*
[16:39:46] <BBB> mru: I'd love to pay you to troll xiph
[16:39:47] <BastyCDGS> BBB, I just posted the latest patch for HAM today
[16:39:48] * BBB runs
[16:40:08] <pJok> BBB, doesn't mru troll xiph for free?
[16:40:09] <_av500_> BBB: i think he has a discount for that...
[16:40:24] * BBB loves discounts
[16:40:25] <_av500_> buy one, troll one free
[16:40:26] <mru> BBB: like the results so far?
[16:40:39] <BBB> mru: couldn't have asked for more
[16:40:46] * BBB brings out popcorn
[16:40:54] <BBB> anything new on the shelves for today, sir?
[16:41:04] * BastyCDGS adds some red whine to it
[16:41:16] <BBB> wine?
[16:41:25] <BBB> (whine == "nag")
[16:41:30] * _av500_ hear a wining noise
[16:41:35] <_av500_> s
[16:41:35] <BBB> not completely, but sort of
[16:41:44] <mru> BBB: maybe it was a pun
[16:42:04] * BBB needs to get native english better
[16:42:06] <BastyCDGS> yes why?
[16:42:39] <BastyCDGS> BBB, didn't mean the win32 API wrapper here ;)
[16:42:44] <mru> just remember, under the strict aliasing rules an english word may never alias a french word
[16:43:02] <BBB> BastyCDGS: wine = the drink
[16:43:12] <BastyCDGS> it's not even an alias in french, mru
[16:43:13] <BBB> BastyCDGS: whine = to be a pain in the ass :)
[16:43:16] <BastyCDGS> wine = vin
[16:43:25] <BastyCDGS> vin rouge = red wine
[16:43:34] * mru knows that much french
[16:43:35] <_av500_> no, thats an editor. no?
[16:44:18] <BBB> poke me if I have to review specific patches
[16:44:18] <BBB> ot
[16:44:27] <BBB> otherwise I'll be off thinking of random stuff to do next
[16:44:37] <mru> you could RE something
[16:44:45] <BastyCDGS> BBB: please review dp8 heavy opt patch and latest HAM ;)
[16:45:56] <BastyCDGS> BBB, as said, the new HAM code also handles IFF PBM raw files correctly
[16:46:04] <BastyCDGS> which was unclear until today
[16:46:12] <BastyCDGS> btw, should I add the new files to the issues?
[16:51:32] <BBB> no, don't triplicate patches
[16:51:35] <BBB> it adds to the noise
[16:51:45] <BBB> maybe start new threads once I've reviewed these
[16:51:47] <BBB> too many patches
[16:51:56] <BastyCDGS> I didn't mean the patches but the IFF files peter sent to me
[16:51:57] <BBB> mru: trying to RE WVP2, but not much time right now
[16:52:02] <BBB> oh
[16:52:03] <BBB> no
[16:52:11] <BBB> contact koth and add them to samples.mplayerhq.hu
[16:52:52] <BastyCDGS> ok...will start new threads when review is done
[16:53:24] <BastyCDGS> although the heavy opt dp8 patch should be fine...there haven't been any critics quite a long time ago on it...
[16:53:50] <mru> that doesn't mean it's fine
[16:53:57] <mru> it's only fine when someone says it is
[16:54:08] <BastyCDGS> yes and that michael said already multiple times
[16:54:30] <BastyCDGS> that he's fine with it
[16:54:53] <BBB> I remember that one being ok, but I'll look and apply
[16:54:55] <BBB> after lunch though
[16:54:56] <BBB> brb
[16:55:05] <BastyCDGS> ok bon appetit
[16:56:34] <BastyCDGS> mru, there's still decodeplane32 there...
[16:57:18] <BastyCDGS> I want to change this reading a whole byte at once too and using an 8-bit table for it
[16:57:43] <BastyCDGS> by using 64-bits as in dp8 the lut has to be changed a little bit
[16:58:03] <BastyCDGS> would you like to assist me in the final #define stuff for declaring the table, too?
[16:58:25] <mru> if you post something too ugly I'll probably complain
[17:00:48] <BastyCDGS> the #define stuff will probably be pretty ugly
[17:01:13] <mru> well, watch and learn
[17:01:45] <mru> every ffmpeg dev knows to embrace the macro
[17:02:03] <mru> and if macros are good, then nested macros are better
[17:02:17] <BastyCDGS> it's just that I'm not experienced with #define hackery
[17:02:32] <mru> how did you ever get anything done?
[17:02:36] <mru> copy&paste?
[17:03:23] <BastyCDGS> actually, I did this sometimes, yes...but I needed only primitive #define's up to now...
[17:03:39] <mru> but where's the fun in that
[17:03:47] <mchinen> anyone on intel mac 10.5 and want to paste me their config flags/changes?  --disable-optimizations --disable-mmx --disable-stripping has those GENERAL_REGS errors in libswscale for me
[17:04:19] <mchinen> (trying to get a build that plays well with gdb)
[17:04:39] <mru> forget gdb
[17:05:15] <BastyCDGS> mru, I just didn't need that often enough to consider complex #define macros useful enough
[17:05:26] <mru> fair enough
[17:06:14] <mchinen> mru: what do you use?
[17:06:19] <BastyCDGS> in TuComposer I backported that 100% asm stuff to C, since the original asm code doesn't need macros, too, I didn't create (except LE/BE stuff) for the C port, too...
[17:06:26] <mru> mchinen: use for what?
[17:06:37] <BastyCDGS> for debugging I suggest...
[17:06:39] <mchinen> mru: for debugging
[17:06:41] <mru> brain
[17:08:11] <mchinen> okay, i'll look into getting one of those later :)
[17:09:59] <spectral_hole> mchinen, valgrind is great for debugging crashes, much better than gdb
[17:10:01] * BastyCDGS adds intuition to brain
[17:10:44] <mru> spectral_hole: only when it's the kind of crash valgrind catches
[17:10:57] <mchinen> spectral_hole: what about as a regular debugger for inspection?
[17:11:08] <mru> why would you want that?
[17:11:17] <mru> printf is much better
[17:11:48] <spectral_hole> Mru, not necessarily: I've had valgrind pick up on bad behavior leading to assert failures and whatnot
[17:11:52] <BastyCDGS> printf + objdump ;)
[17:12:23] <BastyCDGS> at least that does very fine for me now...
[17:13:40] <mchinen> I guess its just a convenience really.  For multithreaded apps it can be a nice one though.
[17:14:05] <mru> for multithreaded apps gdb is _completely_ useless
[17:14:12] <BBB> mchinen: I use 10.6
[17:14:26] <BBB> mchinen: svn with regular configure compiles for me
[17:14:29] <BBB> which file fails for you?
[17:14:41] <mchinen> BBB: yeah regular configure works for me
[17:15:14] <BBB> so which file fails?
[17:15:15] <mchinen> BBB: but adding --disable-mmx --disable-stripping --disable-optimizations breaks libswscale/rgb2rgb.c
[17:15:19] <BBB> ok
[17:15:50] <BastyCDGS> mchinen, I'll test it here, too. now
[17:15:51] <mchinen> there are some guys on windows that this fails for too, but the workaround looks involved so I thought to ask
[17:15:52] <BastyCDGS> with x86
[17:15:55] <mchinen> yeah
[17:16:07] <mchinen> but if no one uses gdb here maybe I should take a hint
[17:16:19] <BBB> I use gdb all the time
[17:16:34] <BBB> even with -O0, rgb2rgb builds fine for me
[17:16:55] <BBB> hm, what's the complete compile line?
[17:16:55] <mchinen> mru: (at least apple's) gdb lets you navigate through threads
[17:17:13] <BBB> linux gdb also
[17:17:15] <BastyCDGS> mchinen it does on ubuntu too
[17:17:16] <BBB> thread 1
[17:17:17] <BBB> thread 2
[17:17:18] <BastyCDGS> yes
[17:17:20] <mchinen> CClibswscale/rgb2rgb.o
[17:17:20] <mchinen> libswscale/rgb2rgb_template.c: In function ‘rgb24toyv12_MMX’:
[17:17:20] <mchinen> libswscale/rgb2rgb_template.c:2081: error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’
[17:17:20] <mchinen> make: *** [libswscale/rgb2rgb.o] Error 1
[17:17:21] <BBB> thread apply all ..
[17:17:25] <mru> yes, but it totally messes up timing between threads
[17:17:30] <BBB> mchinen: gmake V=1
[17:17:31] <mru> and that's usually where the problem is
[17:18:06] <BBB> mchinen: I need the actual gcc command line :)
[17:18:46] <mchinen> ah sorry
[17:18:47] <mchinen> cc -I. -I"/Users/admin/svncheckouts/ffmpeg" -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DPIC -DHAVE_AV_CONFIG_H -std=c99 -fPIC -g -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wundef -Wmissing-prototypes  -fno-math-errno -fno-tree-vectorize         -MMD -MF libswscale/rgb2rgb.d -MT libswscale/
[17:18:56] <mchinen> *thats gcc
[17:19:31] <mchinen> sorry, my paste is messed up.
[17:19:48] <BBB> send it to me by mail
[17:19:53] <BBB> rsbultje at gmail com
[17:21:04] <mchinen> okay, sent
[17:21:45] <BBB> can reproduce now :)
[17:21:51] <BastyCDGS> mchinen just compiled fine for me
[17:22:34] <BBB> there's a -mdynamic-no-pic there on my compile
[17:22:37] <BBB> which fixes it
[17:22:39] <BBB> but shouldn't be there
[17:22:42] <BBB> that's an ugly hack
[17:22:44] <BBB> who added that?
[17:23:18] <mchinen> hm, but it isn't in svn?
[17:23:54] <mchinen> or you mean its in your configure?
[17:24:25] <BBB> it's configure
[17:24:32] <BBB> you probably use ./configure --enable-shared or so
[17:24:41] <mchinen> yeah
[17:24:42] <BBB> anyway, -mdynamic-no-pic fixes this
[17:24:45] <BBB> not a great fix
[17:25:03] <BBB> that breaks sharedlibs though, to my best understanding
[17:25:11] <BastyCDGS> --enable-pic causes problems on x86 too
[17:25:14] <BBB> but it'll work in gd
[17:26:55] <BBB> let's see if I can read this myself
[17:27:15] <BBB> reimar flamed me a while ago for not being able to fix this myself
[17:27:19] <BBB> should be able to fix it now :)
[17:27:28] <mchinen> okay thats fine so I'll just debug with static builds
[17:33:12] <mchinen> yep, static build compiled fine, thanks!
[17:33:34] <BBB> ok
[17:33:52] * BBB would have to actually change the asm to change register constraints and is too lazy for taht :)
[18:53:58] <j-b> ramiro: I love you...
[18:55:18] <BastyCDGS> ohhhh...just as I love my jessica ;)
[18:55:36] <mru> you have a jessica?
[18:56:07] <BastyCDGS> mru, not yet but I'm working on that ;)
[18:59:17] <DonDiego> can somebody point me at a 5.1 channel ac-3 sample?
[18:59:32] * mru points at the nearest dvd
[18:59:58] <BastyCDGS> well I know you can create surround by doing a right channel = ~left channel
[19:00:18] <BastyCDGS> ~ being NOT
[19:00:18] <jai> canyon.ac3
[19:00:27] <jai> or whatever is the actual name
[19:00:39] <mru> Canyon-5.1-48khz-448kbit.ac3
[19:00:46] <jai> yep, that
[19:00:52] <BastyCDGS> that's how I create surround with TuComposer
[19:00:59] <mru> that's not surround
[19:00:59] <DonDiego> oddly, mplayer tells me that it has 2 channels..
[19:01:03] <mru> that's phase shift
[19:01:12] <mru> DonDiego: use ffmpeg
[19:01:38] <BastyCDGS> yes but that does rch = ~lch does, create a surround signal
[19:01:45] <BastyCDGS> see IT docs and specs
[19:02:02] <mru> one cannot create what one does not have
[19:02:03] <J_Darnley> What?  How is 2 channel surround sound?
[19:02:05] <jai> who uses impulsetracker anyway
[19:02:10] <BastyCDGS> it's not true 3D surround
[19:02:21] <DonDiego> mru: impossible, i need to benchmark mplayer..
[19:02:22] <mru> 2D surround is good enough for me
[19:02:42] <BastyCDGS> because you can just tell the tracker if using surround subwoofer etc. sth. alike that
[19:02:44] <mru> otherwise I'd have speakers mounted in the ceiling
[19:03:05] <BastyCDGS> but it works
[19:03:14] <mru> my downstairs neighbour doesn't like my subwoofer
[19:03:22] <mru> it turns her ceiling into a speaker
[19:03:26] <BastyCDGS> but converting that stuff to mono will just kill out any surround channels at well
[19:03:40] <BastyCDGS> FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFff
[19:03:45] <BastyCDGS> 0xFF...
[19:03:46] <mru> uck
[19:04:15] <BastyCDGS> that causes pure silence when converts to mono
[19:04:27] <mru> or if you stand in the wrong spot
[19:04:53] <BastyCDGS> it's not the spot, it's really the mod handling this this way
[19:05:25] <BastyCDGS> even if you have a 64ch module
[19:05:36] <BastyCDGS> i.e. having 64 instruments playing sth.
[19:05:50] <mru> you're confusing concepts
[19:05:52] <BastyCDGS> if you tell just one of them using surround panning
[19:05:59] <mru> 64 voices is not the same as 64-channel sound
[19:06:03] <BastyCDGS> it's not hearable anymore if converted to mono
[19:06:13] <mru> then it's not surround
[19:06:15] <mru> but something else
[19:06:15] <BastyCDGS> 64 voices == 64 channel
[19:06:22] <mru> you are confused
[19:06:36] <BastyCDGS> no I'm not, I just repeating IT specs
[19:06:37] <mru> around here "channel" means physical speaker
[19:07:09] <BastyCDGS> oh ok
[19:07:15] <jai> voices == more like tracks
[19:07:26] <BastyCDGS> in IT of course 64ch doesn't mean 64 physical channels ;)
[19:07:28] <mru> tracks is a bad word to use too
[19:07:32] <jai> :)
[19:07:35] <mru> can be confused with tracks on a cd
[19:07:46] <jai> i meant protools style tracks
[19:07:47] <BastyCDGS> lol you're right
[19:07:49] <BastyCDGS> BUT
[19:07:54] <mru> voices is unambiguous
[19:08:01] <BastyCDGS> the term channels was used in mods 20 years before CDs
[19:08:08] <mru> mods are fringe
[19:08:33] <BastyCDGS> mods are really a great way to encode music
[19:08:36] <Dark_Shikari> even midi was more popular than mod =p
[19:08:46] <BastyCDGS> MIDI is just a subset of MOD
[19:08:49] <BastyCDGS> in fact
[19:08:55] <BastyCDGS> MIDI = MOD + custom samples
[19:09:16] <mru> not really
[19:09:24] <mru> midi is much more than a file format
[19:09:38] <mru> midi is a standard for connecting digital musical equipment
[19:09:39] <jai> yes, kb wrote a nice article on that too
[19:09:50] <BastyCDGS> EIDE is also more popular than SCSI, does it mean that EIDE is better? ;)
[19:10:04] <mru> no, and neither is one a subset of the other
[19:10:06] <BastyCDGS> mru, it isn't a standard really
[19:10:11] * drv runs off to find some betamax tapes
[19:10:20] <mru> depends on what you mean by standard
[19:10:26] <BastyCDGS> unless you stick to 128 samples world-wide
[19:10:27] <mru> every goddamn synth has it
[19:10:41] <mru> that's standard to me
[19:11:11] <BastyCDGS> just try to bring music which you sing yourself with your voice to midi...
[19:11:15] <BastyCDGS> MOD? no problem
[19:11:26] <BastyCDGS> you have to break the "MIDI"-standard for doing this
[19:11:33] <mru> midi is not concerned with the actual samples
[19:11:41] <BastyCDGS> yes and that's the problem!
[19:11:57] <mru> midi only specifies the voice, time, and various parameters
[19:12:02] <mru> like attack and decay
[19:12:05] <BastyCDGS> in fact the actual samples are set in stone
[19:12:15] <mru> yes and no
[19:12:24] <mru> there are a number of predefined voices
[19:12:31] <BastyCDGS> it doesn't specify only that
[19:12:32] <mru> like piano etc
[19:12:47] <mru> it doesn't specify exactly what the piano has to sound like
[19:12:59] <mru> and it's often used with synths where you can build whatever sound you like
[19:13:41] <mru> of course if you record the events, you'll only be able to play it back with the same settings
[19:14:06] <Dark_Shikari> and midi brought us the 80s
[19:14:15] <Dark_Shikari> so it's impossible to argue against.
[19:14:29] <BastyCDGS> sorry lost connection
[19:14:31] <mru> mod is a collection of voice samples and a midi-like list of instructions for playing them
[19:14:33] <BastyCDGS> did I miss sth.
[19:14:37] <Dark_Shikari> 03:14 <@Dark_Shikari> and midi brought us the 80s
[19:14:37] <Dark_Shikari> 03:14 <@Dark_Shikari> so it's impossible to argue against.
[19:14:47] <mchinen> some computer music guys used it for real time synthesis too
[19:15:03] <mru> that's possible
[19:15:12] <mru> it's still much narrower in scope than midi
[19:15:14] <jai> BastyCDGS: we are just saying that midi is more than "general midi + soundbanks"
[19:15:23] <mchinen> i mean midi
[19:15:25] <BastyCDGS> jai, I know this
[19:15:27] <jai> BastyCDGS: http://www.kebby.org/articles/fr08snd1.html
[19:15:29] <Dark_Shikari> http://www.youtube.com/watch?v=A9ol1qLyYwE
[19:15:32] <Dark_Shikari> \o/ midi \o/
[19:15:35] <mru> mchinen: of course
[19:15:38] <BastyCDGS> but MIDI = 128 samples shared amonst all files
[19:15:49] <mru> what files?
[19:15:50] <BastyCDGS> MOD = each module has the samples it exactly needs
[19:16:03] <jai> farbrausch's softsynth uses midi like notation
[19:16:05] <BastyCDGS> .MID files
[19:16:09] <jai> compresses quite well with kkrunchy
[19:16:22] <BastyCDGS> ok
[19:16:38] <BastyCDGS> try to create a song where some guy sings with voice with PLAIN midi
[19:16:56] <mru> that's not a valid argument
[19:17:03] <mru> try to play guitar music on a piano
[19:17:04] <jai> BastyCDGS: though it can be done ... :)
[19:17:20] <BastyCDGS> it it a valid argument, mru
[19:17:22] <mru> midi means Musical Instrument Digital Interface
[19:17:31] <mru> it's for connecting INSTRUMENTS
[19:17:39] <mru> like connecting a keyboard to a synth
[19:17:41] <BastyCDGS> yes, that's true
[19:17:47] <mru> and then performing live
[19:17:49] <mru> with a singer
[19:18:01] <BastyCDGS> MOD = MIDI + custom samples
[19:18:03] <BastyCDGS> ;)
[19:18:10] <mru> recording midi events for later playback is just a side-effect
[19:18:25] <mru> mod = midi subset + custom samples
[19:18:25] <BastyCDGS> with MOD I have both worlds in once
[19:18:44] <BastyCDGS> better:
[19:18:47] <mru> go find a midi spec
[19:18:57] <mru> there's way more to it than just rendering a song on a computer
[19:18:59] <BastyCDGS> mod = (midi subset || mod subset) + custom samples
[19:19:40] <BastyCDGS> duh? I investigated MOD/MIDI stuff over 10 years ago, I know what both advantages/disavantages are there
[19:20:02] <mru> don't the proof by old age on me
[19:20:12] <BastyCDGS> old age?
[19:20:18] <mru> "over 10 years ago"
[19:20:24] <jai> search the ml archives for context
[19:20:26] <jai> ;)
[19:20:33] <mru> as it happens, I was toying with a midi synth 20 years ago
[19:20:41] <Dark_Shikari> http://encyclopediadramatica.com/At_least_100_years_ago
[19:20:43] <mru> without a computer I might add
[19:20:52] <BastyCDGS> or ok to be more mathematically:
[19:20:56] <jai> mru: rs232?
[19:21:02] <mru> jai: MIDI
[19:21:02] <BastyCDGS> MOD = (MIDI UNION samples)
[19:21:09] <mru> it's a 5-pin DIN plug iirc
[19:21:22] <mru> MOD doesn't specify an electrical interface
[19:21:27] <mru> so there
[19:21:31] <BastyCDGS> MOD = MIDI & ~samples;
[19:21:36] <BastyCDGS> sry
[19:21:38] <jai> mru: but over a serial interface right?
[19:21:42] <BastyCDGS> MIDI = MOD & ~samples
[19:21:54] <mru> jai: I assume it's some kind of serial protocol
[19:22:16] <BastyCDGS> mru, should a music format specifiy an external interface?
[19:22:19] <mru> there's a clock somewhere in there too
[19:22:23] <mru> BastyCDGS: no
[19:22:31] <mru> but midi is more than a music file format
[19:22:39] <BastyCDGS> I know
[19:22:47] <BastyCDGS> I'm not saying that MIDI is bad
[19:22:49] <mru> so wtf are you arguing about
[19:23:11] <mru> http://www.midi.org/techspecs/index.php
[19:23:24] <BastyCDGS> but being 100% MIDI compliant just means that all 10000000 songs on the world are based on 128 instruments
[19:23:40] <BastyCDGS> didn't you ever wonder why almost everything from music industry sounds the same?
[19:23:48] <BastyCDGS> it's not lack of creativity
[19:23:54] <mru> did you ever see a band with more than 128 performers?
[19:23:55] <twnqx> DonDiego: did you allow mplayer to use more than 2 channels?
[19:24:03] <BastyCDGS> it's using the same standard 30 years ago with restriction to 128 samples
[19:24:17] <BastyCDGS> yes, I did! mru
[19:24:24] <BastyCDGS> but that's not MIDI anymore
[19:24:37] <mru> a large symphony orchestra might have such numbers
[19:24:41] <twnqx> *with more than 128 performers each playing different instruments or notes
[19:24:45] <BastyCDGS> it's not MIDI as an 24bpp BMP file which was originally designed only for <= 8bpp
[19:25:10] <BastyCDGS> remember, in MIDI samples are FIXED
[19:25:32] <mru> next time you visit the 80s, watch a live band carefully
[19:25:42] <mru> you should notice them tweaking the synths all the time
[19:25:46] <BastyCDGS> you can of course assign a completely different sample to a midi instrument, but it isn't portable anymore
[19:25:56] <mru> it was never meant to be
[19:26:11] <BastyCDGS> yes and that's the problem ;)
[19:26:18] <mru> not really
[19:26:21] <twnqx> and you can load a 100kbyte or 1gbyte piano sample set
[19:26:26] <twnqx> and it will sound totally different
[19:26:28] <twnqx> but who cares?
[19:26:29] <mru> it works fine for a musician who wants to create some music
[19:26:30] <BastyCDGS> yes
[19:26:38] <BastyCDGS> you can even play MIDI on OPL2/3 ;)
[19:26:43] <mru> well...
[19:26:53] <mru> that's a simple fm synth
[19:26:58] * twnqx bought a terratec 32/96 soundcard last year
[19:27:05] <twnqx> just for the mpu401 sample roms
[19:27:20] <BastyCDGS> AWE32 has an huge advantage upon MIDI playback ;)
[19:27:20] <twnqx> just great to play duke nukem 3d on it :P
[19:27:30] <mru> midi was designed to be used by musicians
[19:27:33] <mru> not by consumers
[19:28:02] <BastyCDGS> yeah, like MOD ;)
[19:28:09] <mru> errr, no
[19:28:18] <mru> mod is the distribution format
[19:28:22] <mru> midi is not
[19:28:29] <twnqx> mod doesn't even allow panning :>
[19:28:39] <BastyCDGS> twnqx LOL
[19:28:40] <mru> you're arguing that a cd player is better than a piano
[19:28:46] <mru> because the piano can only play piano music
[19:28:52] <BastyCDGS> this is untrue twnqx
[19:29:04] <mru> there are many different mod formats too
[19:29:09] <BastyCDGS> ImpulseTracker supports 256 bit pan + surround sound pan
[19:29:10] <mru> some with more features than others
[19:29:17] <twnqx> rally? last i checked you needed it, s3m or the like for .mod
[19:29:29] <twnqx> err for pannig
[19:29:42] <twnqx> impulse tracker uses .it files :P
[19:30:14] <BastyCDGS> mru, yes there are tons of MOD formats around
[19:30:22] <BastyCDGS> and all being not good documented
[19:30:34] <BastyCDGS> that's why I was developing TuComposer ;)
[19:30:47] <BastyCDGS> TuComposer should unifiy all those like as MIDI ;)
[19:31:10] <BastyCDGS> funny...really funny...
[19:31:36] <BastyCDGS> you're just complaing that I was solving 10 years ago with TuComposer (that's even the only reason I invented it ;-))
[19:32:24] <BastyCDGS> and that is the reason I want to use TuComposer's engine in FFmpeg for playback modules
[19:32:50] <BastyCDGS> because I have adressed all your issues 10 years ago
[19:32:54] <mru> I'm not complaining
[19:33:05] <BastyCDGS> I know the bad things about mod files
[19:33:19] <BastyCDGS> it's exactly that what you're complaing right now
[19:33:26] <mru> I'm not complaining
[19:33:26] <BastyCDGS> non-standard conforming etc.
[19:33:39] <mru> I couldn't care less about mod files
[19:34:21] <BastyCDGS> mru, I don't wonder about this really...
[19:34:55] <BastyCDGS> like you coudn't care less about any amiga stuff, right? ;)
[19:35:00] <BastyCDGS> that's okay for me...
[19:35:04] <mru> I had a couple of friends who'd spend all day in front of their amigas playing mods
[19:35:09] <mru> I never saw the point
[19:35:13] <mru> I had a cd player
[19:35:48] <BastyCDGS> well just try to get 18096 songs on a CD with CDDA ;)
[19:36:18] <mru> I'll rather have just one album of real music than a lifetime of mashed-up mods
[19:36:19] <drv> 18096 songs of dubious quality
[19:36:20] <BastyCDGS> 18096 that's the number of MODs (i.e. totally different songs) on the MODs anthology
[19:36:46] <BastyCDGS> why dubious quality?
[19:36:48] <ramiro> j-b: hm, what did I do this time?
[19:36:55] <drv> there are a few really god mods, and many more mediocre ones
[19:36:58] <mru> ramiro: he found your old liborc flame
[19:37:12] <drv> s/god/good/ :)
[19:37:21] <BastyCDGS> god == good ;)
[19:37:50] <mru> a skilled composer can of course create a good song using the mod features
[19:38:03] <ramiro> oh =)
[19:38:13] <BastyCDGS> yes, almost all mod trackers can deal with MIDI directly
[19:38:21] <j-b> ramiro: those people don't seem to understand what Xcompilation is
[19:38:22] <BastyCDGS> i.e. you can combine them perfectly
[19:38:23] <ramiro> it's still not fixed though. lib<whatever the name is now> doesn't work for win64
[19:38:27] <BastyCDGS> but not the other way around
[19:38:31] <mru> can they take input from my physical keyboard in realtime?
[19:38:38] <BastyCDGS> yes
[19:38:41] <BastyCDGS> they can
[19:38:46] <mru> I mean a piano-like thing
[19:38:51] <mru> connected to the midi port
[19:38:55] <BastyCDGS> you can even use the original midi instrument or a custom sampled one
[19:38:59] <mru> (no, I don't actually have one)
[19:39:00] <ramiro> j-b: he seriously considers it "not a bug" that a build system should silently fail on cross-compilation
[19:39:07] <drv> some trackers do have midi input
[19:39:28] <j-b> ramiro: You _really_ should read their autogen.sh script
[19:39:29] <mru> and can they output over the midi port to control a real synth?
[19:39:32] <BastyCDGS> drv, ehmm which one? I haven't seen any tracker for over 10 years ago which can't do this
[19:39:38] <BastyCDGS> IT can handle MIDI perfectly
[19:39:51] <BastyCDGS> yes mru, they can
[19:39:55] <BastyCDGS> IT can do this
[19:39:55] <drv> i think modplug can
[19:40:03] <drv> but it's been a long time since i messed with it
[19:40:33] <BastyCDGS> IT was able to do this in 1998
[19:40:46] <BastyCDGS> on a 486 with 64 channels
[19:40:51] <BastyCDGS> with max. quality
[19:40:54] <mru> eh, wasn't mod pretty dead by then?
[19:40:58] <BastyCDGS> MIDI + sampled
[19:41:15] <BastyCDGS> MIDI is still the 1st standard in the demo scene
[19:41:22] <BastyCDGS> even many games use it
[19:41:38] <BastyCDGS> oops
[19:41:42] <drv> well, the demo scene and the real world seldom intersect
[19:41:43] <j-b> ramiro: depending on the result of whoami, the configuration is different...
[19:41:47] <BastyCDGS> meant MOD is still the 1st standard...
[19:41:52] <Dark_Shikari> games still use it?  I haven't seen it used in games for ages
[19:42:00] <Dark_Shikari> the last game I saw that used midi was the older touhou games
[19:42:01] <drv> most gams just use vorbis or something these days
[19:42:06] <Dark_Shikari> and those are indie, made by a PC-98-age guy
[19:42:08] <ramiro> j-b: ah, that's liboil, right? I remember seeing that some time ago
[19:42:13] <ramiro> sad, very sad.
[19:42:14] <BastyCDGS> dark_shiraki: was writing wrong meant MODs sry
[19:42:16] <Dark_Shikari> and even he stopped releasing midi versions of his tracks
[19:42:19] <Dark_Shikari> BastyCDGS: never seen a game use mods ever
[19:42:23] <Dark_Shikari> Not a modern game at least
[19:42:28] <Dark_Shikari> where "modern" means "since windows 95"
[19:42:48] <BastyCDGS> apogee games
[19:43:03] <mru> doesn't sound modern
[19:43:14] <ramiro> not to mention that it has --disable-static forced in autogen.sh
[19:43:25] <aaronl_> there's a pretty cool platformer that came out recently called vvvvvv
[19:43:29] <aaronl_> and it has some great chiptunes
[19:43:37] <ramiro> he "not a bug"d my bug report that it didn't build statically
[19:43:44] <aaronl_> but i was disappointed to find out that they're all prerendered
[19:43:46] <ramiro> even though configure doesn't fail
[19:43:49] <j-b> ramiro: no, schroedniger too
[19:43:50] <aaronl_> what has the world come to? :(
[19:44:19] <BastyCDGS> mru, yes I know that apogee was morely known to titles like Duke Nukem 3D and alike (although DN3D used MIDI nod MOD)
[19:44:30] <twnqx> <3
[19:44:43] <BastyCDGS> but there were lots of games from them during this time which used MOD
[19:44:51] <twnqx> i payed >300DM for my soundcard in those days, for the hardware wavetable...
[19:44:52] <mru> eh, duke nukem was 3drealms
[19:45:13] <BastyCDGS> apogee bought 3drealms
[19:45:13] <twnqx> and i bought it again, used, for 2€ :X
[19:45:26] <BastyCDGS> if i remember correct at least
[19:45:28] <ramiro> twnqx: what's a DM?
[19:45:33] <BastyCDGS> all that's been long time ago
[19:45:34] <twnqx> german mark.
[19:45:42] <BastyCDGS> maybe I'm remembering sth. wrong
[19:46:47] <BastyCDGS> but, MIDI isn't really cheap, instead it's really expensive
[19:47:13] <mru> there's cheap midi gear and expensive midi gear
[19:47:19] <BBB> ok, time for review
[19:47:22] <BastyCDGS> I read countless of interviews with DJs / etc. who had to pay much much money for getting all the software together just to compose
[19:47:25] <BastyCDGS> >= 10000 €
[19:47:31] <BBB> where's the patch?
[19:47:37] <BastyCDGS> with mod you'll get the same with a usual 486 PC
[19:47:44] <mru> I don't think so
[19:48:01] <mru> midi is just what ties it all together
[19:48:23] <BastyCDGS> ok, then tell my why such software like adobe audition (former CoolEdit) requires an Pentium 3/4 for 8ch realtime mixing while IT can do 64ch on 486SX-25?
[19:48:25] <mru> a good keyboard or a good synth is still expensive
[19:48:30] <ramiro> BastyCDGS: were you part of multimedia mike's blog's flame war on trackers?
[19:49:04] <BBB> mru: any progress on making the sine table generator a separate file?
[19:49:06] <mru> I bet the mixing quality of the former is far better than the latter
[19:49:17] <mru> BBB: was I working on that?
[19:49:27] <BastyCDGS> I mean realtime mixing for playback
[19:49:28] <BBB> one of the two of us should
[19:49:32] <BBB> and it's not me
[19:49:42] <BastyCDGS> IT had way better algorithms for disc recordings
[19:49:42] <BBB> so I freely volunteered you ;)
[19:49:49] <mru> well, a pro DJ might have slightly higher standards than a basement kid with an amiga
[19:50:03] <BastyCDGS> I'm talking of PC tracker software
[19:50:06] <BastyCDGS> not of amiga
[19:50:11] <mru> kid with a pc then
[19:50:13] <BastyCDGS> the amiga was just the start of this
[19:50:29] <mru> and the middle and most of the end
[19:50:35] <BastyCDGS> IT was never available on amiga
[19:50:40] <mru> it only came to pc because they stopped making amigas
[19:50:45] <twnqx> neither s3m or ft2, right?
[19:50:45] <BastyCDGS> and most amiga trackers could just handle 4ch at maximum
[19:50:49] <mru> I mean mod stuff in general
[19:51:06] <mru> and anything else of the amiga mindset
[19:51:13] <BastyCDGS> twnqx, yes the trackers itself were never available to amiga
[19:51:26] <BastyCDGS> but amiga had (although bad) players for 'em
[19:51:41] <jai> ft2 sucked on my 386
[19:51:48] <twnqx> mru: in those days you couldn't handle 20MB .mp3
[19:52:13] <twnqx> so if you wanted decent music, tracked was the only real way
[19:52:19] <mru> or play CDs
[19:52:24] <twnqx> err
[19:52:32] <twnqx> i meant as background music in games, etc
[19:52:36] <BastyCDGS> mru, you're talking of playback, we're talking of recording
[19:52:39] <jai> ut used mods iirc
[19:52:44] <drv> some PC games used CD as background music ;)
[19:52:45] <BastyCDGS> yes UT did
[19:52:45] <mru> twnqx: games often used CD music actually
[19:52:50] <BastyCDGS> and a lot of other games too
[19:52:56] <twnqx> few
[19:53:10] <twnqx> also there where days before cd-roms...
[19:53:14] <twnqx> were*
[19:53:24] * mru remembers when cdroms attached to the soundblaster
[19:53:44] * twnqx remember QIC80 streamers connected in parallel to floppy drives
[19:53:44] <BastyCDGS> even in the CD-ROM time they used mods...the CDDA tracks were MODs pretty often
[19:53:59] <BastyCDGS> just they were using 16-bit samples like S3M/XM/IT offered
[19:54:16] <BastyCDGS> mru, I had a CD-ROM drive needed to attach on SB ;)
[19:54:20] <BastyCDGS> I know all this ;)
[19:54:23] <mru> not the ones where you could pop the game disc in a cd player, skip to track 2 and hear the game music
[19:54:47] <BastyCDGS> mru, you didn't need that even on mod
[19:54:50] <jai> i still have the nascar racing cdrom with a bunch of skidrow tracks :)
[19:55:05] <BastyCDGS> you can change to 10000 different songs even without switching CDs ;)
[19:56:03] <BastyCDGS> hey guys
[19:56:18] <BastyCDGS> please DO NOT mix damn old MOD format from 1980 with 2010 module formats
[19:56:18] <mru> nevertheless, midi was designed as tool for musicians
[19:56:23] <BastyCDGS> or even 1998 like IT
[19:56:49] <drv> who needs mods in 2010? we have terabyte hard disks, gigabytes of RAM, megabit/s internet...
[19:56:53] <twnqx> then don't call it mod, 'cause mod is just that old format from amiga
[19:56:58] <BastyCDGS> mru, as said: MIDI = MOD + samples
[19:57:02] <mru> for live performance or recording onto studio tapes
[19:57:19] <jai> drv: tracked music is still very important
[19:57:20] <twnqx> drv: and they all sound like crap compared to some nice c64 chiptunes.
[19:57:22] <BastyCDGS> twnqx you're right, but I did just for sake of less complexity
[19:57:32] <mru> I know what midi is, and it's got very little to do with mod
[19:57:32] <BastyCDGS> do you want me writing each time:
[19:57:43] <BastyCDGS> MOD/S3m/XM/IT/669/MMM/etc.?
[19:57:54] <mru> do you play an instrument? do you know any real musicians?
[19:57:55] <BastyCDGS> I just collect them to mod
[19:58:19] <BastyCDGS> me? I do tracking, yes.
[19:58:23] <twnqx> i collect them to tracked music
[19:58:28] <mru> I mean instruments
[19:58:35] <twnqx> but whatever :]
[19:58:38] <mru> the kind you pluck, strike, etc
[19:58:59] <BastyCDGS> partially I do, but it's more basic stuff like piano
[19:59:04] <jai> i do, and i use a MIDI controller too ;)
[19:59:36] <jai> BastyCDGS: again, general midi is the spec which defines soundbanks, and is not to be confused with the original midi spec
[20:00:01] <BastyCDGS> jai, I know this, but the soundbanks are pressed in stone
[20:00:07] <mru> I'm talking about the one that has phycical cables
[20:00:17] <mru> plugging into physical machines
[20:00:18] <BastyCDGS> i.e. sample 0x8C is always a piano for example.
[20:00:21] <jai> BastyCDGS: mru is not referring to general midi
[20:00:26] <mru> that people press keys on to produce notes
[20:00:34] <jai> i think...
[20:01:12] <BastyCDGS> yes and that causes MIDI all the trouble with it, there are samples defined from 0-255
[20:01:22] <BastyCDGS> but they're all set in stone by official standard
[20:01:41] <BastyCDGS> changing from this causes all incompatibilities you could think off
[20:01:50] <twnqx> so?
[20:01:58] <twnqx> what exactly is your point?
[20:02:12] <BastyCDGS> that MOD was designed to solve these issues
[20:02:15] <twnqx> no
[20:02:28] <BBB> BastyCDGS: the 16-bit rounding was applied right?
[20:02:28] <BastyCDGS> just attach the stuff you need custom to your song file and it's fine.
[20:02:56] <twnqx> both have very different foundations, as mru pointed out
[20:03:03] <BastyCDGS> BBB, dunno understand...what you mean with 16-bit rounding here?
[20:03:20] <BBB> I think carl eugen applied it
[20:03:22] <BBB> word-alignment
[20:03:29] <twnqx> .mid was never (really) meant to be exchanged, but for local storage in your setup
[20:03:31] <mru> general midi is a standardised set of voices and whatnot
[20:03:38] <BastyCDGS> oh ok word-alignment patch was applied already
[20:03:49] <BastyCDGS> but I was talking about dp8 heavy opt patch
[20:03:57] <BastyCDGS> i.e. the one doing AV_WN64A etc.
[20:04:34] <BastyCDGS> yes twnqx and that is what mod differs, it is designed esp. for exchange ;)
[20:04:48] <BastyCDGS> but even here lots of mod tracker writers fail
[20:05:00] <BastyCDGS> they don't document their formats as they should be
[20:05:13] <BastyCDGS> and so every player outputs different stuff as it should
[20:05:27] <BastyCDGS> and then I had enough of this and TuComposer was born
[20:05:36] <BastyCDGS> (The united Composer = TuComposer)
[20:05:48] <mru> mod is a midi-inspired distribution format for electronic music
[20:06:03] <mru> midi is a studio tool
[20:06:19] <mru> or stage as the case may be
[20:06:58] <BastyCDGS> both are studio tools indeed ;)
[20:07:12] <mru> those who have only encountered midi as annoying background music on web pages c 1996 don't know what it really is
[20:07:16] <BastyCDGS> mods are much more free in doing music
[20:07:23] <mru> eh?
[20:07:25] <BastyCDGS> it's like freedom compared from windows to linux
[20:07:29] <ramiro> BastyCDGS: you didn't answer, but this is the post I was talking about http://multimedia.cx/eggs/renoise-xrns/
[20:07:29] <mru> bollox
[20:08:31] <BastyCDGS> mru, as I already said
[20:08:40] <BastyCDGS> MOD = MID + free samples
[20:08:48] <BastyCDGS> attached to file
[20:09:00] <ramiro> free samples like the ones we get on the market?
[20:09:01] <mru> free? wtf?
[20:09:06] <BastyCDGS> FREE samples
[20:09:19] <BastyCDGS> this includes these you record with your own micros
[20:09:27] <ramiro> free samples suck. the package is always much smaller than the ones they sell on the store.
[20:09:29] <BastyCDGS> .WAV/.FLAC/.VOC/etc.
[20:09:33] <mru> I could make a mod file and forbid extraction and reuse of the samples
[20:09:36] <BastyCDGS> anything you want...ANYTHING!
[20:09:48] <BastyCDGS> not just stuck to a 128 set
[20:10:06] <ramiro> BastyCDGS: anything really? can you put goatse in it?
[20:10:15] <drv> goatse for your ears
[20:10:16] <BastyCDGS> YES! it's PCM!!!
[20:10:24] <mru> goatse is jpeg...
[20:10:32] <BastyCDGS> of course you can produce shice with PCM recording
[20:10:41] <BastyCDGS> but is that a fault of MOD standard or the recorder?
[20:11:17] <mru> I'm not saying MOD is bad at what it does
[20:11:29] <mru> but calling it "better" than MIDI is senseless
[20:11:31] <BastyCDGS> oh then I probably got you wrong
[20:11:37] <mru> they serve different purposes
[20:11:44] <BastyCDGS> yes they indeed do ;)
[20:12:04] <mru> like I said, you can't claim a CD player is better than a piano because the piano can only play one kind of music
[20:12:07] <BastyCDGS> that's what I'm try to tell you about an hour ;)
[20:12:15] <BastyCDGS> I never did this
[20:12:50] <mru> no, but close
[20:12:56] <BastyCDGS> I just was comparing a fixed 128 samples format to any samples format
[20:13:04] <mru> midi isn't fixed
[20:13:08] <mru> it's unspecified
[20:13:15] <mru> you can program your synth as you see fit
[20:13:22] <BastyCDGS> yes that's what my problems with it are actually ;)
[20:13:29] <mru> no, that's not a problem
[20:13:34] <mru> it's not an interchange format
[20:13:41] <_av500_> gee
[20:13:54] <BastyCDGS> oh I remember times where it was told MIDI is just that ;)
[20:13:55] <mru> if you stick the general midi constraints, yes you get some interoperability
[20:14:05] <mru> *stick to
[20:14:17] <BastyCDGS> I understand you, no panic ;)
[20:14:32] <mru> so why do you keep telling me that mod is better than midi
[20:14:34] <mru> ?
[20:14:47] <BastyCDGS> because mathematically midi is a subset of mod
[20:14:47] <mru> cars are better than apples too?
[20:15:02] <mru> I'd argue the opposite
[20:15:09] <BastyCDGS> i.e. you can represent EVERYTHING in midi what is possible with mod but not the way other around
[20:15:21] <mru> that makes midi a superset
[20:16:04] <mru> a mod file is a sequence of midi events + voice samples
[20:16:10] <mru> or midi-like
[20:16:12] <BastyCDGS> I'm talking about pure note data
[20:16:25] <BastyCDGS> in these parts MIDI and MOD are on same level
[20:16:45] <mru> I don't know the exact details on either so I can't argue about that
[20:16:51] <BastyCDGS> but where MOD is far ahead is that you can reprogram the samples to anything you want
[20:16:58] <mru> but the MIDI 1.0 spec says nothing at all about voices
[20:17:32] * _av500_ hears voices in his head, does not know the spec though
[20:17:55] <BastyCDGS> whenever I want to sing something I just take a quality microphone record it i.e. with audacity
[20:17:59] <mru> you're expected to program the voices yourself
[20:18:03] <BastyCDGS> and add that just to a MOD
[20:18:15] <BastyCDGS> this isn't possible with MOD without breaking MIDI standard
[20:18:21] <mru> the noly problem is if you want to distribute your work _as raw midi data_
[20:18:34] <_av500_> you have to ship the synth too
[20:18:40] <mru> and that's what mod does
[20:18:44] <BastyCDGS> it's not a problem, with MOD I can do this without worrying anything
[20:18:55] <jai> yes, smf+softsynth could be used for interchange
[20:19:12] <mru> or a real synth, if the recipient has the same model
[20:19:21] <jai> sure
[20:19:33] <_av500_> BastyCDGS: in fact you cant, unless you ship a sample of every note played
[20:19:53] <_av500_> as the synth defines the sound in the end
[20:20:01] <BastyCDGS> av500, that's why I use mod instead ;)
[20:20:22] <_av500_> thats like shipping the pcm then
[20:20:29] <BastyCDGS> I just ship the same stuff as I would with MIDI just the custom samples I created attached with it ;)
[20:20:36] <BastyCDGS> no it's not!
[20:20:39] <_av500_> but that is one sample per note
[20:20:46] <BastyCDGS> no it isn't
[20:21:06] <mru> "it isn't" or "it's not"... make up your mind
[20:21:22] <BastyCDGS> you can play ANY sample with ANY note with an mod
[20:21:36] <mru> only the samples included in the file
[20:21:44] <BastyCDGS> you don't have to recreate your samples for each different note you play!
[20:21:53] <_av500_> BastyCDGS: yes, but the synth coudl
[20:22:02] <_av500_> therefore midi does not define it
[20:22:12] <ramiro> this channel has been seeing a lot of caps lately...
[20:22:47] <_av500_> BastyCDGS: i could have that totally cool song with my random note synth
[20:22:49] <BastyCDGS> av500: sorry didn't understand you right now, what you mean by not defining it?
[20:23:07] <BastyCDGS> av500: perfectly possible with mods
[20:23:08] <_av500_> as i said, note c does not have to be a slower d
[20:23:23] <BastyCDGS> av500: this isn't with mods...
[20:23:55] <mru> a synth is allowed to behave in all sorts of non-linear ways
[20:24:15] <BastyCDGS> formula: f = base_freq * pow(transpose,1/12);
[20:24:15] <_av500_> and to put it in a mod file you need to toall characterise it
[20:24:23] <_av500_> totally
[20:24:27] <_av500_> BastyCDGS: no
[20:24:39] <_av500_> that assumes each sample is the same
[20:24:46] <_av500_> just faster/slower
[20:24:48] <_av500_> how lame
[20:24:48] <BastyCDGS> nope
[20:24:48] <mru> a traditional synth is a piece complex analogue electronics
[20:25:00] <BastyCDGS> base_freq is sampling rate of original sample
[20:25:11] <_av500_> yes, one per note
[20:25:37] <BastyCDGS> av500: I know there are problems with mod formats ;)
[20:25:42] <mru> there are many more parameters too
[20:25:46] <BastyCDGS> esp. these you're mentioning here
[20:26:01] <BastyCDGS> and that's just why I invented TuComposer
[20:26:03] <_av500_> and i even dont know what .mod is :)
[20:26:09] <mru> most importantly velocity
[20:26:13] <_av500_> until i read this backlog
[20:26:37] <_av500_> ffmpeg-devel took my evening away...
[20:26:52] <BastyCDGS> btw, TuComposer can play much more notes per channel than MIDI
[20:27:01] <BastyCDGS> it supports NNAs etc.
[20:27:13] <_av500_> mru: dont forget the voltage instability in that small shady club...
[20:27:20] <BastyCDGS> NNA = New Note Action
[20:27:37] <BastyCDGS> this means that the composer can decide what happens exactly when a new note is being played
[20:27:47] <BastyCDGS> normally old notes are simply being cut
[20:27:50] <mru> mod is basically a patch mixer
[20:28:10] <mru> you can have midi without a single sound patch
[20:28:15] <BastyCDGS> with NNA you can tell the tracker what do do exactly if you're playing a new note on the same channel what happens with old note
[20:28:29] <mru> as is the case with an analogue synth
[20:28:32] <mru> or a digital one
[20:28:53] <BastyCDGS> there's NNA cut (old behaviour), NNA off (keyoff), NNA fade (trigger fadeout) and NNA continue (just continue playing note)
[20:28:54] <mru> or in the extreme, a real, electrically actuated piano
[20:29:08] <BastyCDGS> with TuComposer there's even a NNA synth
[20:29:22] <mru> I bet tucomposer doesn't contain an actual piano
[20:29:32] <BastyCDGS> i.e. trigger a synth assembler code on this where you can exactly decide what to happen on assembly language level
[20:29:47] <_av500_> oh, a vm
[20:29:59] <_av500_> you send java sound event :)
[20:30:10] <BastyCDGS> yes it's a kind of VM but such fast it even can do larger programs on 68040/25
[20:30:19] <BastyCDGS> (which equals to 486SX_25)
[20:30:57] <mru> but can I enter the schematics for a moog synth and have the right sound pop out?
[20:31:04] <BastyCDGS> my "VM" is fast enough to do 64ch realtime mixing on CD quality on an old 486
[20:31:51] <BastyCDGS> mru, what do you mean with moog synth exactly?
[20:31:56] <mru> rotfl
[20:32:02] <BastyCDGS> as said it's an real assembler
[20:32:14] <ramiro> geez, you play with electronic music and you don't know what a moog is?
[20:32:18] <BastyCDGS> so as long as your plans are turing possible it should be possible ;)
[20:32:22] <_av500_> lol
[20:32:46] <mru> reminds me of the guy who'd never "experienced the halting problem"
[20:32:57] <_av500_> brookie
[20:33:03] <_av500_> ftw
[20:33:16] <BastyCDGS> who tells you I'm not knowing this? maybe I just know this under a different name, possibly?
[20:33:29] <mru> not likely
[20:34:02] <mru> http://www.vintagesynth.com/moog/moog.php
[20:34:03] <BastyCDGS> btw, there's no halting problem, actually, just put off the power supply and everything will halt: 100% ;)
[20:34:11] <mru> there you go, bit of history
[20:34:39] <mru> of course, those didn't have midi interfaces
[20:34:52] <mru> but that could be easily added
[20:35:15] <BastyCDGS> just looked at your side, and of course you can do this with tucomposer's synth assembler
[20:35:16] <mru> with a uC and some DACs
[20:35:24] <BastyCDGS> it will be just some lot of code, though
[20:35:43] <BastyCDGS> remember it's a complete assembly language like x86 / m68k
[20:35:46] <mru> realtime simulation of a non-linear circuit
[20:35:48] <mru> I don't think so
[20:36:22] <mru> and I don't even play music....
[20:36:25] <_av500_> mru: not even if we overclock that 486?
[20:36:33] <ramiro> lol
[20:37:19] <BastyCDGS> well go here for a small example:
[20:37:20] <BastyCDGS> http://forum.cdgs-crew.com/viewtopic.php?t=16
[20:37:35] <BastyCDGS> it shows you of capabilities of tucomposer's synth asm
[20:37:47] <BastyCDGS> and I already use it for playback of FC13/14 modules
[20:38:30] <BastyCDGS> av500: overclocking? of the 486? why?
[20:38:41] <_av500_> nvm
[20:38:45] <BastyCDGS> it isn't needed for high quality sound output
[20:39:27] <BBB> was the dp8 optimization applied?
[20:39:38] <BastyCDGS> just because we today know shice soft like adobe stuff doesn't mean we can get hq sound output on old processors ;)
[20:39:49] <BastyCDGS> BBB, not yet :(
[20:39:52] <BBB> hm
[20:39:53] <BBB> why?
[20:40:06] <BBB> I thought that one was well-tested?
[20:40:06] <BastyCDGS> I dunno, Carl Eugen didn't say anything why
[20:40:16] <BBB> he didn't reply in that thread
[20:40:22] <BBB> michael and I both ok'ed it
[20:40:31] <BastyCDGS> yes that wondered me too
[20:40:39] <BBB> did you test that on BE/LE?
[20:40:43] <BastyCDGS> yes I did
[20:40:48] <BastyCDGS> thanks to mru ;)
[20:40:54] <BastyCDGS> he did provide an BE machine
[20:40:58] <BastyCDGS> and I tested it there
[20:41:33] <BastyCDGS> after all the BE/LE issues was the reason he did a patch for endianess constants
[20:41:36] <BBB> I think it's because your last message in the thread sayd:
[20:41:37] <BastyCDGS> for tables
[20:41:41] <BBB> "Could the revert this patch, please?
[20:41:42] <BBB> I just found a serious bug in the original code, which I believe which
[20:41:42] <BBB> is the cause that some IFF images (like MRLake.iff) are displayed
[20:41:42] <BBB> partially incorrect."
[20:41:43] <_av500_> bobby?
[20:41:56] <BBB> you didn'ty reply after, so we assume you're still working on it
[20:42:02] <BastyCDGS> oh...
[20:42:09] <BBB> better fix that :)
[20:42:10] <BastyCDGS> could be possible
[20:42:21] <BastyCDGS> it's been done since some time ;)
[20:42:33] <CIA-7> ffmpeg: michael * r23059 /trunk/libavutil/ (log.c log.h avutil.h): Add means to adjust the log level per context.
[20:42:37] <BastyCDGS> I was writing this when I wasn't sure for myself what is was
[20:43:05] <BastyCDGS> but the latest patch to git/svn shows that it's ok
[20:43:14] <BBB> hm
[20:43:16] <BBB> why is it inline?
[20:43:17] <BastyCDGS> in fact we do just divide the loop by 8
[20:43:25] <BastyCDGS> and do an WN64A
[20:43:58] <BastyCDGS> I was doing this inline on the first attempts because it really made a difference upon that time
[20:44:05] <BastyCDGS> but today it's not required anymore
[20:44:17] <BBB> the code here does a AV_W32() in dp8
[20:44:21] <BastyCDGS> gcc just inlines because we shortened sooo much for itself
[20:44:25] <BBB> W64() is for dp32 right?
[20:44:31] <BastyCDGS> ehhmm...
[20:44:43] <BastyCDGS> we replaced it with WN64A long time ago ;)
[20:44:55] <BBB> then the patch I'm looking at is old
[20:44:57] <BastyCDGS> mru did optimization of table for this
[20:45:06] <BastyCDGS> yes looks so ;)
[20:45:09] <BBB> I think you're confusing dp32/dp8
[20:45:18] <BBB> dp8 looks like an ideal candidate for W32
[20:45:23] <BastyCDGS> nope dp8 has to be revised completely
[20:45:26] <BastyCDGS> 32
[20:45:27] <BastyCDGS> sry
[20:45:38] <BastyCDGS> dp32 I meant
[20:45:58] <BBB> ok so start back at the beginning
[20:46:05] <BBB> I'm talking about the following patch:
[20:46:07] <BBB> decodeplane8()
[20:46:10] <BBB> where is the latest version?
[20:46:13] <BastyCDGS> dp32 has to be rewritten completely
[20:46:19] <BBB> the one Michael and I ok'ed was using W32
[20:46:23] <BastyCDGS> wait a moment, will get it out
[20:47:03] <BBB> start a new thread
[20:47:06] <BBB> I'm majorly confused
[20:47:09] <BBB> and do ONE SINGLE PATCH
[20:47:10] <BBB> no more
[20:47:12] <BBB> just one
[20:47:21] <BBB> if anything else is necessary, start a new thread and put the thread on hold
[20:47:30] <BBB> don't ever post more than one patch in a thread
[20:47:34] <BBB> 2 is ok, 3 is a mess
[20:47:38] <BBB> more than three is where we are now
[20:47:45] <BBB> i.e. totally confusing the hell out of me :)
[20:47:52] <BBB> (and everyone else)
[20:48:21] <BBB> also, if you can, install the google "oops" plugin, the one that lets you cancel sent messages
[20:48:31] <BBB> you have a lot "oops this patch wasn't right" 5-second-afters
[20:49:01] <BBB> ok, let's look at the real patches now ;)
[20:49:09] <BastyCDGS> I just submitted to ml
[20:50:22] <BBB> the title of the email is: "[FFmpeg-devel] [PATCH] Fix non-rounding up to next 16-bit aligned bug in IFF decoder"
[20:50:31] <BBB> how am I supposed to guess that this is an optimization email?
[20:50:45] <BastyCDGS> that's correct
[20:51:00] <BastyCDGS> sorry did post it before reading your IRC stuff
[20:51:04] <BBB> you probably want to change the subject :)
[20:51:38] <BastyCDGS> I was adding this in the past to this thread because my patch depended on this patch in this thread
[20:52:05] <BastyCDGS> but since my original patch is already applied I should change this maybe...
[20:52:38] <BastyCDGS> sorry I'm just getting hard to follow here (thanks to wine)
[20:53:29] <BBB> ok, so all the int -> unsigned is not ok, they make no difference (see michael's earlier comment on ffmpeg-svn mailinglist)
[20:53:43] <BBB> as long as they're not used in a division, there is no reason really
[20:53:47] <BBB> bps is unused anyway
[20:54:23] <BBB> plane is only used as a table index, and buf_size isn't used anywhere relevant also
[20:54:24] <BastyCDGS> ??? i dunno understand
[20:54:30] <BastyCDGS> was just looking at my patch
[20:54:42] <BBB> I'd in fact recommend to change the buf_size * 8 into a buf_size << 3, if you want ot do anything at all :)
[20:54:46] <BastyCDGS> it justs adds a table
[20:54:55] <BastyCDGS> << 3????
[20:54:58] <BBB> that *might* (probably wouldn't, but might) make a difference
[20:55:05] <BastyCDGS> that's completely unnecessary
[20:55:14] <BBB> the int->unsigned changes are also
[20:55:27] <BastyCDGS> I'm having here:
[20:55:29] <BastyCDGS> +    const unsigned b32 = b & ~3;
[20:55:29] <BastyCDGS> +    const uint32_t lut[] = {0x0000000,
[20:55:29] <BastyCDGS> +                            0x1000000 << plane,
[20:55:38] <BastyCDGS> but there's no << 3...
[20:56:10] <BBB> iff-decoder-fix-heavy-dp8.patch
[20:56:13] <BastyCDGS> just wondering where it originates from...
[20:56:14] <BBB> +#define LUT8_PART(plane, v)                             \
[20:56:15] <BBB> +    AV_LE2ME64C(UINT64_C(0x0000000)<<32 | v) << plane,  \
[20:56:16] <BBB> [..]
[20:56:20] <BBB> +#define LUT8(plane) {                           \
[20:56:20] <BBB> +    LUT8_PART(plane, 0x0000000),                \
[20:56:21] <BBB> [..]
[20:56:26] <BBB> +static const uint64_t plane8_lut[8][256] = {
[20:56:26] <BBB> +    LUT8(0), LUT8(1), LUT8(2), LUT8(3),
[20:56:28] <BBB> [..]
[20:56:35] <BBB> and then the changes to decodeplane8()
[20:56:39] <BBB> that is the patch, right?
[20:56:42] <BastyCDGS> yes and in the main I have only:
[20:56:42] <BastyCDGS> +    const uint64_t *lut = plane8_lut[plane];
[20:56:42] <BastyCDGS> +    for(; --buf_size != 0; dst += 8) {
[20:56:42] <BastyCDGS> +        const uint64_t v = AV_RN64A(dst) | lut[*buf++];
[20:56:42] <BastyCDGS> +        AV_WN64A(dst, v);
[20:57:02] <BastyCDGS> but your table doesn't fit
[20:57:21] <BastyCDGS> it should be:
[20:57:21] <BastyCDGS> +#define LUT8_PART(plane, v)                             \
[20:57:21] <BastyCDGS> +    AV_LE2ME64C(UINT64_C(0x0000000)<<32 | v) << plane,  \
[20:57:24] <BBB> check before that
[20:57:25] <BastyCDGS> and:
[20:57:33] <BastyCDGS> +#define LUT8(plane) {                           \
[20:57:33] <BastyCDGS> +    LUT8_PART(plane, 0x0000000),                \
[20:57:33] <BastyCDGS> +    LUT8_PART(plane, 0x1000000),                \
[20:57:51] <BBB> go to the patch
[20:57:51] <ramiro> BastyCDGS: pastebin
[20:57:52] <BBB> not the code
[20:57:54] <BBB> but the patch
[20:58:05] <BastyCDGS> did I apply the wrong patch then?
[20:58:09] <BBB> hm
[20:58:09] <BBB> nm
[20:58:16] <BBB> mru already replied to the mailinglist saying what I said :)
[20:58:23] * BBB pokes mru
[20:58:37] <BastyCDGS> I just took a look in my mail I sent
[20:58:49] <BastyCDGS> and it still shows the stuff I mentioned above
[20:58:54] <BastyCDGS> what did I do wrong?
[20:59:47] <BBB> you change the function prototype
[20:59:52] <BBB> there's no reason to
[21:00:02] <BastyCDGS> you mean this?
[21:00:03] <BastyCDGS> +static void decodeplane8(uint8_t *dst,
[21:00:03] <BastyCDGS> +                         const uint8_t *buf,
[21:00:03] <BastyCDGS> +                         unsigned buf_size,
[21:00:03] <BastyCDGS> +                         const unsigned bps,
[21:00:03] <BastyCDGS> +                         const unsigned plane)
[21:00:16] <BBB> yes
[21:00:25] <BBB> they're all only used as index or not at all
[21:00:31] <BBB> so unsigned/int makes no difference
[21:00:52] <BastyCDGS> this is not true, it does for plane e.x.
[21:00:57] <mru> and const even less so
[21:01:10] <BastyCDGS> since that's used as index
[21:01:26] <mru> not to mention the gratuitous line breaks
[21:01:42] <BBB> you only use plane once
[21:01:48] <BBB> so const or no const makes no difference
[21:01:55] <BBB> bps is unused
[21:02:04] <BBB> so const makes no difference
[21:02:09] <mru> const can only make a difference on pointers
[21:02:27] <BastyCDGS> oh bps is unused, thank you mentoning that
[21:02:44] <BBB> I bet you he will send a patch removing it in the same patch as adding the optimization now
[21:02:46] <BastyCDGS> that's really sth. to remove from func
[21:02:47] <BBB> :-p
[21:02:51] <_av500_> compiler would still complain if you modify "const plane", no?
[21:03:09] <BBB> _av500_: -Wall doesn't work anyway
[21:03:15] <BBB> so it's not like anyone would notice
[21:03:23] <BBB> -Werror, I meant
[21:03:35] <mru> modifying a const is an error
[21:03:43] <mru> but it doesn't affect optimisation
[21:03:55] <mru> it's only an aid to avoid accedentally changing something
[21:04:06] <BastyCDGS> mru, all my optimizations tutorial tell me to use const for optimizing
[21:04:09] <_av500_> yep, that is what i meant
[21:04:15] <_av500_> BastyCDGS: ???
[21:04:16] <mru> BastyCDGS: burn those tutorials
[21:04:22] <BBB> BastyCDGS: probably in tables, as mru said
[21:04:24] <drv> const on local scalars is completely pointless
[21:04:29] <BBB> for tables, const is good
[21:04:38] <BBB> it puts it in .rodata (or whatever it's called)
[21:04:40] <mru> const is good on global data
[21:04:50] <BastyCDGS> av500, I already seen diffs on this
[21:05:00] <mru> it also means the compiler can assume it won't change over time
[21:05:10] <BastyCDGS> I thought that it's unnecessary quite a long time
[21:05:23] <BastyCDGS> I used non-const in TuComposer too...
[21:05:34] <BastyCDGS> until I learned that it can make a diff
[21:05:41] <mru> hard to get anything done with only const data
[21:05:47] <BBB> *grin*
[21:05:55] <BBB> BastyCDGS: show us that the output changes
[21:06:09] <mru> optimising C is a bit like breaking md5
[21:06:19] <mru> keep trying inputs until you get the desired output
[21:06:28] <BastyCDGS> BBB, I can show this for my TuComposer source compiling with StormC
[21:07:04] <wbs> StormC wasn't one of the supported ffmpeg compilers, last I checked
[21:07:09] <wbs> or is it?
[21:07:10] <mru> please give the author of that compiler a ticket here
[21:07:13] <mru> one-way is good enough
[21:07:18] <mru> he won't be needing the return
[21:07:22] <BastyCDGS> mru, Haage & Partner
[21:07:41] <BBB> BastyCDGS: you're only using plane once
[21:07:48] <BBB> BastyCDGS: const or not const makes no difference in this case
[21:07:52] <ramiro> BastyCDGS: what's the link to tucomposer again?
[21:07:59] <mru> even if he used it a million times const would make no difference
[21:08:11] <mru> nothing external to the function can modify a local variable
[21:08:12] <BBB> I just tried on iff.o
[21:08:13] <BastyCDGS> ramiro: http://forum.cdgs-crew.com/viewforum.php?f=11
[21:08:13] <_av500_> StromC: The progressive C/C++ development system for the Amiga's future
[21:08:23] <BBB> making int plane -> const in decodeplane8() in current svn changes the md5
[21:08:29] <BBB> that's about as much as I tested :)
[21:08:36] <mru> BBB: with debug symbols?
[21:08:43] <BBB> god damn you :)
[21:08:51] <mru> strip the files before comparing
[21:09:03] <mru> if it still differs, extract the .text section
[21:09:12] <ramiro> BastyCDGS: Wed 01 Jun, 2005 ?
[21:09:22] <BastyCDGS> yeah stripping and comparing them was that I was doing all the times when devloping TuComposer
[21:09:48] <BBB> mru: in progress
[21:10:06] <BastyCDGS> ramiro, that date was when I putted them in WWW, but actual coding was done in 1996-98
[21:10:30] <ramiro> I thought tucomposer was a modern tracker
[21:10:38] <mru> that's an oxymoron
[21:10:40] <BastyCDGS> it is ramiro
[21:10:59] <mru> just like there are no modern steam engines
[21:11:06] <ramiro> mru: I read that expression in mike's blog, it was supposed to be funny =)
[21:11:12] <mru> never mind the nuclear stuff
[21:11:40] <BastyCDGS> ramiro, just because I didn't hat in 2010 doesn't mean it's not modern
[21:11:46] <ramiro> BastyCDGS: is there any recent code for it?
[21:11:54] <ramiro> released somewhere...
[21:12:01] <BastyCDGS> the most recent code you find exactly there
[21:12:09] <ramiro> pre-ALPHA?
[21:12:18] <BastyCDGS> the only caveat is though it's amiga only
[21:12:19] <mru> code that old tends to a) not compile and b) be ugly as sin
[21:12:46] <BastyCDGS> that's the reason I declared it pre-ALPHA
[21:12:57] <BastyCDGS> on amiga itself it's rockstable
[21:13:00] <ramiro> since 1996?
[21:13:09] <BastyCDGS> it decodes over 1000+ mods without crash
[21:13:11] <mru> ramiro: yes, that's pre-alpha... I got my first alpha machine ~2000
[21:13:26] <BastyCDGS> it all them plays absolutely and I mean absolutely perfectly
[21:14:12] <BastyCDGS> just try it to bring tucomposer's decoder to crash, just try it ;)
[21:14:48] <BastyCDGS> it handles mods/s3ms/xms/its which cause even up-to-state linux decoders to crash
[21:14:55] <BastyCDGS> like opencubicplayer etc.
[21:15:15] <mru> I thought you said there were 18096 MODs
[21:15:48] <mru> and let's compile it first, shall we?
[21:15:48] <BastyCDGS> well I tested them with just of my 1000 main modules
[21:16:22] <BastyCDGS> and of course I sometimes tried them with my mods anthology CD
[21:16:31] <mru> did you try a fuzzer?
[21:16:31] <BastyCDGS> but until now it was always finee
[21:17:23] <BastyCDGS> do you mean a tool which corrupts mods in order to check if they're correct?
[21:17:45] <mru> well... something like that
[21:17:49] <mru> you're on the right track
[21:17:58] <mru> guaranteed no pun intended
[21:17:59] <mru> hahaha
[21:18:01] <BBB> mru: md5 changes
[21:18:14] <BastyCDGS> well I didn't use that directly, but what I did was to load tons on modules which even don't comply to standard and I had to ensure conversation issues in order to get them right
[21:18:34] <BBB> mru: will look at .text in a bit
[21:18:38] <BBB> first trying another control
[21:20:48] <BastyCDGS> I just can tell that I wasn't able to trigger fatal bugs in TuComposer between the time from 1994-1998
[21:21:11] <mru> testing can only prove the presence of bugs, never their absence
[21:21:37] <BastyCDGS> I know ;)
[21:22:02] <_av500_> bugs can prove the absence of testing though :)
[21:22:39] <BastyCDGS> guys, I'm writing about 4 years of consequence testing...
[21:22:54] * mru is not impressed
[21:23:02] <BastyCDGS> not just of starting a tool and see: uhm, there's an error
[21:23:05] <BBB> hm
[21:23:10] <BBB> the actual disassembly didn't change
[21:23:13] <BBB> did a quick diff
[21:23:15] * mru is not easily impressed
[21:23:24] <mru> BBB: see, told ya :-)
[21:23:36] <BBB> why did the md5 change?
[21:23:42] <BBB> stupid false negative
[21:23:45] <BBB> or false positive
[21:23:49] <BastyCDGS> mru, you should be that skeptical as you are right now ;)
[21:24:00] <drv> maybe the object file has a timestamp in it or something?
[21:24:17] <mru> do a binary diff and see
[21:25:20] <BBB> I don't give a shit :)
[21:25:20] <mru> so I open a random file in tucomposer, and what do I see?
[21:25:24] <mru> UNDEFINED BEHAVIOUR
[21:25:41] <BBB> BastyCDGS: I just showed the const didn't make a difference
[21:25:48] <BBB> BastyCDGS: so please remove the const :)
[21:25:49] <mru> nevermind the ugly style
[21:25:58] <BBB> and while you're at it, change the unsigned back to int as mru suggested
[21:26:14] <BBB> rest of patch looks good, so I'll apply once that's done
[21:26:34] <BBB> mru: no more comments on the patch right?
[21:26:38] <BastyCDGS> wait a minute, I'll do that now
[21:26:41] <mru> nothing more from me
[21:27:22] <BBB> ok
[21:27:34] <BBB> what was the next patch
[21:27:35] <BBB> ?
[21:27:38] <BBB> ham decoding, right?
[21:27:42] <BastyCDGS> yes HAM
[21:27:46] <BBB> I'll take that home with me to review, will send it back tonight or so
[21:29:07] <BastyCDGS> just one question
[21:29:20] * BBB awaits question
[21:29:27] <BastyCDGS> do you mean I should convert all unsigned to int?
[21:29:37] <BBB> no
[21:29:42] <BBB> just the ones in the function prototype
[21:29:45] <BastyCDGS> -static void decodeplane8(uint8_t *dst, const uint8_t *const buf, int buf_size, int bps, int plane)
[21:29:46] <BBB> there's no reason to change them
[21:29:50] <BBB> yes
[21:29:52] <BBB> just as it was
[21:30:35] <BastyCDGS> I disagree that there's no reason to change them but if you force me to do so...
[21:30:52] <BBB> if you give us a good reason and show it, then you may change them
[21:31:09] <BBB> until you do so, let's leave it as-is, going by our rule that "patches should be as simple as possible"
[21:31:18] <BastyCDGS> from user's point of view:
[21:31:20] <BBB> for new code, you may do as you wish, of course :)
[21:31:27] <BBB> (since it makes no difference)
[21:31:39] <BastyCDGS> I should anywhere know if some value should be designed to be signed/unsinged, right?
[21:31:40] <BBB> although smaller sourcecode size is always better
[21:31:54] <BBB> values aren't signed or unsigned alone
[21:31:57] <BBB> they have a valid range
[21:32:03] <BBB> some values can have 0-5 as valid range
[21:32:06] <BBB> such as log_level
[21:32:06] <BastyCDGS> yes that's what I meant ;)
[21:32:14] <BBB> signed or unsigned are both wrong
[21:32:18] <BBB> so it's irrelevant which you choose
[21:32:20] <BastyCDGS> and that's what I mean with plane etc.
[21:32:28] <BastyCDGS> a plane < 0 makes no sense right?
[21:32:31] <wbs> BastyCDGS: doing readability/understandability changes that have no impact on performance doesn't belong in an optimization patch, it's as simple as that
[21:32:34] <BBB> plane is 0<plane<=8
[21:32:46] <BBB> so signed is as wrong as unsigned
[21:32:51] <BastyCDGS> yes, therefore plane is unsigned
[21:32:58] <BastyCDGS> since 0<plane... ;-)
[21:32:59] <BBB> the proper way to specify a value is to properly document the value
[21:33:13] <BastyCDGS> the base here is IFF-ILBM
[21:33:14] <BBB> no, because unsigned can be 12, or 0x80000000, or something else
[21:33:23] <BastyCDGS> and IFF-ILBM is ALWAYS unsigned on that
[21:33:23] <BBB> it's a false sense of security
[21:33:32] <BBB> the proper way to do it is to document the correct values
[21:33:37] <BBB> and check for them in the function body
[21:33:42] <BBB> (where appropriate)
[21:33:48] <BBB> in your case, you do that in decode_init()
[21:33:50] <BBB> so you're fine
[21:33:51] <_av500_> BastyCDGS: plane < 0 makes as much sense a plane = INT_MAX
[21:33:52] <BastyCDGS> yes I agree to this totally BBB
[21:34:39] <BastyCDGS> plane < 0 will trigger nothing, while pane = INT_MAX will segfault
[21:34:50] <BastyCDGS> and thus showing us all that something is really wrong
[21:35:20] <BBB> let's just agree it doesn't matter much ;)
[21:35:29] <BBB> learn to properly document values, not look at type
[21:35:31] <BastyCDGS> we can of course!
[21:35:40] <BastyCDGS> but I really don't like that
[21:35:41] <BBB> whether a user sees signed or unsigned, in both cases it's incomplete
[21:35:49] <BBB> only 8 of the 1<<32 values possible are correct
[21:35:56] <BBB> regardless of signed/unsigned
[21:36:12] <BastyCDGS> remember that uint/int stuff causes already a lot of trouble
[21:36:30] <BastyCDGS> some hw doesn't support FAT files with 4GB some do etc.
[21:36:39] <BBB> btw where is the patch?
[21:36:57] <mru> FAT itself doesn't support >2G
[21:37:17] <BastyCDGS> it does but the unsigned/signed stuff is causing problems
[21:37:31] <BastyCDGS> FAT can handle 4GB if cluster size => unsigned
[21:38:20] <BastyCDGS> I know that most of you don't deal much with that stuff (unsigned <=> singed)
[21:38:30] <mru> careful what you say
[21:38:30] <BBB> ?
[21:38:36] * BBB smiles a bit
[21:38:39] <BastyCDGS> but the days when we devel'ld on amiga we had to really care ab't that
[21:39:08] <_av500_> why?
[21:39:10] <BastyCDGS> on amiga UWORD was really UWORD and handling this as WORD was FATAL!
[21:39:24] <mru> funny you should say that
[21:39:32] <BastyCDGS> the structures we had there was designed for such stuff...
[21:39:39] <mru> because that is *exactly* what I randomly say you doing in tucomposer just now
[21:40:04] <BBB> BastyCDGS: let's get back to the patch, please submit it
[21:40:12] <BBB> BastyCDGS: and then submit a second patch where you remove the int bps parameter
[21:40:22] <BastyCDGS> mru, no in TuComposer I showed for each variable and decided for each if it should be unsigned or not
[21:40:23] <BBB> then I'll look at ham
[21:40:26] <BastyCDGS> do not mix that up
[21:41:00] <CIA-7> ffmpeg: stefano * r23060 /trunk/ffplay.c:
[21:41:00] <CIA-7> ffmpeg: Fix auto-scaling.
[21:41:00] <CIA-7> ffmpeg: Use the numeric value assigned to sws_flags for the sws_flags set in
[21:41:00] <CIA-7> ffmpeg: the graph, rather than the string "bilinear", which is not even
[21:41:00] <CIA-7> ffmpeg: parsable by the scale filter.
[21:41:19] <mru> WORD *OldWaveData = WaveformStr->tcyw_WaveData;
[21:41:23] <mru> WORD WavePoint;
[21:41:26] <BastyCDGS> mru, if you change TuComposer's code regarding this, you can be 99,99% sure that it will break playback
[21:41:27] <mru> WavePoint = (UWORD) *OldWaveBuf++;
[21:41:32] <mru> wtf is that then?
[21:41:47] <BastyCDGS> looks like m68k C code ;)
[21:42:05] <mru> looks clueless to me
[21:42:20] <BBB> uword looks portable
[21:42:21] <mru> you're probably hoping the cast will do nothing
[21:42:25] <mru> and it probably won't
[21:42:28] <BBB> as opposed to int, int16_t or so :)
[21:42:30] <BastyCDGS> UWORD = uint16_t
[21:42:33] <mru> but it is undefined
[21:43:20] <BastyCDGS> mru, my TuComposer source result is designed carefully on what compiler result (in his case StormC)
[21:43:30] <mru> rotfl
[21:43:39] <mru> does the term "portable code" have a meaning to you?
[21:43:44] <BastyCDGS> I tried a hell to get most performing result
[21:43:48] <mru> how about "ISO C"?
[21:44:10] <BastyCDGS> mru, I know there have to be changes
[21:44:32] <BastyCDGS> and I know that the current code isn't perfect regarding this
[21:44:33] <BBB> I love gcc
[21:44:36] <BBB> look at this:
[21:44:38] <BBB> libavcodec/iff.c:145: error: increment of read-only location
[21:44:45] <BBB> now, guess what what this line does
[21:45:04] <BBB> ...
[21:45:04] <BBB> ...
[21:45:05] <BBB> ...
[21:45:05] <BBB>         const uint64_t v = AV_RN64A(dst) | lut[*buf++];
[21:45:25] <drv> which thing is const?
[21:45:29] <BBB> const uint8_t *const buf
[21:45:33] <_av500_> BastyCDGS: wrt FAT, you are again wrong, for FAT using uint32_t matters, for plane it does not
[21:45:39] <drv> well, that's incorrect code then
[21:45:40] <mru> BBB: all of it is const there
[21:45:51] <BBB> it's a little lol :)
[21:45:53] <BBB> too many consts
[21:45:56] <BBB> I'll remove them all
[21:45:57] <mru> "const type *foo' is pointer to const
[21:45:58] <BBB> they do nothing
[21:46:01] <BastyCDGS> av500, ehm that's my code ;)
[21:46:04] <mru> "type *const foo" is const pointer
[21:46:48] <mru> "Please read everything in this section carefully, all of the words are important."
[21:46:53] <mru> ^^ found in the FAT spec
[21:46:55] <BastyCDGS> but av500 I'm not saying that a plane is > 2^311
[21:47:02] <BastyCDGS> but it's always >= 0
[21:47:13] <BastyCDGS> and that's why I'm using unsigned here
[21:47:30] <_av500_> no, plane is a small number
[21:47:32] <_av500_> line int i
[21:47:36] <_av500_> like int i;
[21:47:42] <_av500_> u dont care, so it is int
[21:47:47] <BastyCDGS> yes it is
[21:47:57] <mru> "Please don’t draw an incorrect conclusion here."
[21:48:00] <mru> that spec is funny
[21:48:15] <BastyCDGS> FAT is really "nice" here
[21:48:17] <drv> sounds like "it's ok if you do that elsewhere, just not here"
[21:48:31] <BastyCDGS> depending on target OS you have max. file size 4GB or 2GB
[21:48:56] <_av500_> BastyCDGS: no, there are just broken implementations
[21:49:09] <_av500_> and they have been there a long time
[21:49:28] <_av500_> so other asumed that was correct...
[21:49:33] <BastyCDGS> really hard to answer, if that's broken or M$ specs
[21:49:45] <CIA-7> ffmpeg: rbultje * r23061 /trunk/libavcodec/iff.c: Optimize decodeplane8(), patch by Sebastian Vater <cdgs basty googlemail com>.
[21:49:45] <_av500_> fat supports 4gb files just fine
[21:50:01] <BastyCDGS> yes that's what I was just assuming
[21:50:11] <BastyCDGS> 4GB files are correct (uint32_t)
[21:50:22] <_av500_> sure, as i said, there it matters
[21:50:22] <mru> Reserved for use by Windows NT. Set value to 0 when a file is created and never modify or look at it after that.
[21:50:24] <BastyCDGS> but they aren't when you do int32_t (<= 2GB)
[21:50:50] <_av500_> but this is not relevant for your unsigned issue
[21:51:08] <BastyCDGS> av500, you're right here also
[21:51:16] <BastyCDGS> but what we should do finally?
[21:51:38] <BastyCDGS> just assume that everything is unsigned
[21:51:57] <BBB> I already applied the patch
[21:51:57] <BastyCDGS> and then wonder why any example which requires this goes bad?
[21:52:01] <BBB> let's go to the ham patch
[21:52:28] <_av500_> BastyCDGS: no
[21:52:28] <BastyCDGS> I know you're all from x86 where unsigned isn't hat an issue
[21:52:31] <_av500_> no
[21:52:33] <_av500_> no
[21:52:35] <BastyCDGS> but let me tell you
[21:52:35] <drv> everything unsigned can have unintended consequences too
[21:52:39] <BastyCDGS> I'm from amiga
[21:52:39] <_av500_> use it where it matters
[21:52:43] <BastyCDGS> and I can tell you
[21:52:52] <BastyCDGS> UNSIGNED makes here a big difference
[21:52:55] <_av500_> dont use it where it does not
[21:53:01] <BastyCDGS> if in doubt just read IFF specs
[21:53:29] <BastyCDGS> drv, you're totally right !!!
[21:53:45] <BastyCDGS> and amiga formats really are dependent on this!
[21:53:52] <drv> well, that's not really what i meant
[21:54:01] <drv> like if you write a count-down loop with an unsigned iterator
[21:54:15] <drv> or other less than/greater than comparisons don't do what you expect
[21:54:27] <BastyCDGS> yes and even this can make a huge diff between a normal signed counter
[21:54:56] <BastyCDGS> drv, that's WHY i use unsigned because they act different (and also are faster one some machines)
[21:54:58] <mru> ok, FAT spec says filesize is unsigned 32-bit
[21:55:09] <mru> anything pretending otherwise is by definition wrong
[21:55:26] <BastyCDGS> mru, you see? do you now understand a little bit why I'm so picky on this?
[21:55:33] <mru> not at all
[21:55:38] <_av500_> BastyCDGS: no
[21:55:39] <mru> I simply misremembered
[21:56:10] <_av500_> BastyCDGS: if the number needs 32 bit, you have to use uint32
[21:56:21] <_av500_> if the number needs a few bits, just use int
[21:56:22] <BastyCDGS> yes  I know
[21:56:23] <mru> unless it needs signed 32-bit...
[21:56:30] <BastyCDGS> av500: I use int
[21:56:38] <BastyCDGS> but unsigned if it's never <= 0
[21:56:48] <mru> no
[21:56:50] <_av500_> and this is useless
[21:56:53] <mru> depends
[21:56:56] <_av500_> and or dangerous
[21:57:00] <BastyCDGS> no it's not useless
[21:57:02] <mru> I've seen horrible bugs caused by that
[21:57:18] <BastyCDGS> any value never be < 0 (i.e. negative) should be declared unsigned
[21:57:22] <mru> unsigned foo = some_random_data;
[21:57:34] <mru> while (foo - 2 > 0) { ...; foo--; }
[21:57:35] <BastyCDGS> it shows the programmer that this value never has to be neg.
[21:58:06] <_av500_> BastyCDGS: the programmer does not matter, its not like he does the computation on paper
[21:58:23] <BastyCDGS> av500: the programmer just writes the stuff
[21:58:25] <mru> that turns into an infiniloop if foo is odd
[21:58:54] <BastyCDGS> hey guys, I don't tell you this to argue you
[21:59:07] <mru> you're suppose to be learning from us
[21:59:12] <drv> mru: maybe foo -= 2? otherwise i think it would terminate
[21:59:17] <BastyCDGS> I just want to help from my experiences
[21:59:22] <BastyCDGS> mru, I know
[21:59:24] <mru> drv: well, yeah
[21:59:30] <BastyCDGS> and I'm learning a lot from you
[21:59:34] <BastyCDGS> you know this
[21:59:38] <mru> well, the amiga experience isn't of much use to us
[21:59:54] <BastyCDGS> yes that what is understanding to me
[22:00:14] <BastyCDGS> but where not discussing about how great the amiga was/it ;)
[22:00:24] <mru> the real bug I saw was slightly different
[22:00:26] <mru> it was like this
[22:00:28] <BastyCDGS> we're discussing about import of formats
[22:00:35] <mru> unsigned short foo = blah;
[22:00:48] <mru> while (foo - 2 > 0) { ...; foo -= 2; }
[22:01:00] <BastyCDGS> and in the case of formats it simply counts how the origin was defined
[22:01:08] <mru> then someone decided to "fix" a lint warning
[22:01:08] <BastyCDGS> and therefore you simply look at BMHD etc.
[22:01:13] <BastyCDGS> and you see:
[22:01:17] <mru> made it while (foo - 2u > 0u)
[22:01:21] <BastyCDGS> EVERYTHING is unsigned
[22:01:21] <mru> and it inifinilooped
[22:01:23] <BastyCDGS> NOT signed
[22:01:36] <mru> bmhd?
[22:01:38] <_av500_> BastyCDGS: you dont want to understand
[22:01:47] <BastyCDGS> FORM-ILBM => BMHD
[22:02:08] <BastyCDGS> av500: don't panic, I understand your concerns too
[22:02:20] <_av500_> panic, moi?
[22:02:25] <mru> without the u suffix, the unsigned short was promoted to signed int and the comparison worked
[22:02:31] <BastyCDGS> but it's not really that easy as we ALL (that includes me too) might believe
[22:02:34] <BastyCDGS> at first glance
[22:04:18] <BastyCDGS> mru, which WORD to UWORD  conversation you mean?
[22:04:46] <BastyCDGS> resp. UWORD => WORD?
[22:04:58] <mru> ConvertWaveform.c
[22:05:04] <mru> it's full of casts
[22:05:31] <BastyCDGS> you mean in TuComposer?
[22:05:35] <mru> yes
[22:05:50] <BastyCDGS> mom have to start UAE to look on this...
[22:06:08] <mru> huh?
[22:06:20] <mru> the zip file unpacks reasonably well on any machine
[22:06:30] <mru> half the files are executable for no reason, but nevermind
[22:06:51] <_av500_> mru: but it is signed vs unsigned char for the src code :)
[22:06:59] <_av500_> changes the meaning totall
[22:07:00] <_av500_> y
[22:07:28] <BastyCDGS> oh I got the casts
[22:07:46] <BastyCDGS> I added them to allow any C++ compiler to compile them just fine
[22:08:28] <mru> why do you compile c code with a c++ compiler?
[22:09:24] <BastyCDGS> because I was naive enough during this time
[22:09:47] <BastyCDGS> mru, I won't do this anymore today
[22:10:09] <BastyCDGS> I have already told my problems with my old stuff
[22:10:57] <BastyCDGS> please never forget....
[22:11:13] <BastyCDGS> I have translated all this from 100% m68k asm to C
[22:11:18] <BastyCDGS> line by line
[22:11:42] <BastyCDGS> every line you read there is pratically one asm line on m68k
[22:14:20] <mru> why the heck did you write it in asm first?
[22:14:36] <BastyCDGS> mru, very good question
[22:14:50] <BastyCDGS> assign this to the stupiest ideas of mankind ;)
[22:14:51] <mru> writing critical parts in asm makes sense of course
[22:15:00] <mru> but I'd always write it in C first
[22:15:15] <BastyCDGS> mru, you're completely right here
[22:15:35] <BastyCDGS> but I was naive and idotic enough to don't do that this way ;)
[22:16:09] <BastyCDGS> I know it might sound strange to you
[22:16:24] <BastyCDGS> but that's what I can tell you for truth
[22:16:26] <mru> I've done silly things too
[22:16:38] <mru> but I don't use them as reference now
[22:17:11] <BastyCDGS> I understand this pretty well now
[22:17:25] <BastyCDGS> but still I know I do some hazardous stuff for now
[22:20:17] <BastyCDGS> do you know what me really wonders?
[22:20:26] <mru> no
[22:20:40] <BastyCDGS> the picy stuff about unsigned/signed here...
[22:21:44] <BastyCDGS> why where wasting lots of time upon this, etc.?
[22:22:04] <mru> I believe it was you who started changing them
[22:22:17] <BBB> BastyCDGS: we want small patches
[22:22:20] <BBB> as small as possible
[22:22:23] <BastyCDGS> yes, indeed and no for bad reason ;)
[22:22:29] <BBB> imagine that you do a huge performance-enhancing patch to h264
[22:22:34] <BBB> we would REALLY REALLY WANT THAT
[22:22:35] <BBB> ok
[22:22:41] <BBB> now, half of the patch is int->unsigned changes
[22:22:44] <mru> I know you have good intentions
[22:22:47] <BastyCDGS> I understand why you want signed stuff as much was possible
[22:22:48] <BBB> and the patch is like 10k
[22:22:51] <BBB> we will not look at it
[22:22:55] <BBB> because it's too much
[22:23:03] <BBB> we're tyrying to teach you good patch-handling techniques here
[22:23:23] <BBB> so that when you go do bigger projects, (hopefully here), the patches will not be of good, but of outstanding quality
[22:23:37] <BBB> signed/unsigned is irrelevant
[22:23:41] <BastyCDGS> BBB, are my patches really causing so much big additions?
[22:23:49] <BBB> the patch should be as small as possible
[22:24:10] <wbs> if there's no practical reason for changing something, don't change it, even if you think it is better some other way
[22:24:22] <wbs> if you really, really, really want to change it, change it in a separate bikeshed patch
[22:24:30] <BBB> BastyCDGS: and at some point, yes, you will give us huge patches, at least I hope so
[22:24:51] <BastyCDGS> if I change something to uint instead int I know why I'm doing so
[22:25:01] <BBB> you might
[22:25:06] <BBB> but we have to review it nonetheless
[22:25:13] <BastyCDGS> but I also understand why you're such criticial about this
[22:25:16] <BBB> and int>uint in the same patch as adding a lut, is noise
[22:25:16] <wbs> and if it isn't essential, don't change it!
[22:25:29] <BBB> the point of decodeplane8() optimization was the lut
[22:25:32] <BBB> the patch should add a lit
[22:25:38] <BBB> not change int->unsigned :)
[22:25:50] <BBB> (you could do that, but as wbs suggested, separate patch)
[22:26:20] <BastyCDGS> BBB, thank you for that
[22:26:24] <BBB> by the way, note how the optimization patch was reviewed several times, how people really get what the patch does
[22:26:30] <BBB> and the 32->64bit change made it even more fast
[22:26:48] <BBB> if the patch had random stuff in it, or we weren't knowledgeable, we wouldn't have done that
[22:27:02] <BBB> ffmpeg is high-quality because we go through it, in iterations, in this maddening way :)
[22:27:04] <BastyCDGS> yeah we spent all together lots of time to get this going on  ;)
[22:27:10] <BBB> and that way we're 20% faster than everyone else out there
[22:27:14] <BBB> because we bikeshed too much
[22:27:20] <BastyCDGS> BBB, I love youj!
[22:27:32] <BBB> holy shit ;)
[22:27:40] <BastyCDGS> that's what ffmpeg is about ;)
[22:28:05] <BastyCDGS> hey, we're crazy
[22:28:10] <BastyCDGS> we're all crazy
[22:28:23] <BBB> ok, I just reviewed the ham patch, it's a lot again, but we'll get it in in a few iterations
[22:28:26] <BastyCDGS> but: that's gooooooood!
[22:28:32] <BBB> and yes we're crazy
[22:28:59] <BastyCDGS> that what I'm saying ;)
[22:29:15] <BBB> ok, my wife will come home in a bit
[22:29:20] <BBB> I'd better be there when she does
[22:29:21] <BBB> so I'm off now
[22:29:31] <BastyCDGS> hehe I understand
[22:29:41] <BastyCDGS> so you know what I mean with my Jessica ;)
[22:29:55] <BBB> you're married too?
[22:30:00] <BBB> how old are you? :)
[22:30:07] <mru> amiga age obviously
[22:30:15] <BastyCDGS> not married yet, but could happen very soon ;)
[22:30:29] <BastyCDGS> I'm 30
[22:30:45] <BBB> and still not married?
[22:30:51] <BBB> :-p
[22:30:52] * BBB runs
[22:30:53] <mru> I would've thought you a few years older with the amiga stuff
[22:31:02] <mru> BBB: I'll be 30 this year
[22:31:12] <mru> no marriage in sight
[22:31:19] * BBB throws mru some women
[22:31:20] <BastyCDGS> mru, I got 30 on 4th feb 2010
[22:31:32] <BBB> ok, really off now ;)
[22:31:50] <BastyCDGS> BBB, wish me some luck with jessi ;)
[22:31:51] <mru> BBB: thanks, but the women all bounced
[22:31:57] <mru> BastyCDGS: good luck
[22:32:04] <BastyCDGS> hey thanks
[22:32:05] <BBB> good luck indeed
[22:32:08] <BBB> propose tonight ;)
[22:32:09] <_av500_> send pics
[22:32:41] <BastyCDGS> av500 can't she didn't send px to me
[22:32:48] <BastyCDGS> but what I can
[22:32:53] <BastyCDGS> sending a mod
[22:32:54] <BastyCDGS> ;)
[22:33:54] * _av500_ goes to sleep, listening to canyon.mid...
[22:34:17] <BastyCDGS> lol canyon.mid I know this one very well :D
[22:35:21] <BastyCDGS> if someone of you are goa freaks, though...