December 28, 2014 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
December 28, 2014 [01:56:46] *** mat^2 has joined #openal[01:56:46] *** ChanServ sets mode: +v mat^2[02:24:56] *** Smirftsch3 has joined #openal[02:24:56] *** ChanServ sets mode: +v Smirftsch3[02:26:29] *** Smirftsch1 has quit IRC[03:52:53] *** marynate has joined #openal[03:52:53] *** ChanServ sets mode: +v marynate[04:45:27] *** prophile has quit IRC[06:40:21] *** marynate has quit IRC[06:40:48] *** marynate has joined #openal[06:40:48] *** ChanServ sets mode: +v marynate[07:39:58] *** mat^2 has quit IRC[09:03:48] <Smirftsch3> is it right to assume that both ogg and mp3 in alure only work with the streaming functions? and if so, is there a way to decode the entire stream at once nevertheless?[09:04:38] <Smirftsch3> i only need it to play small sequences which would be wav otherwise, not entire music files[09:04:48] <KittyCat> no, it should work to fully load them into buffers too[09:05:00] <Smirftsch3> oh, good morning :)[09:05:32] <Smirftsch3> well, it returns unsupported type for me when trying[09:05:40] <Smirftsch3> maybe something is wrong in my build then[09:06:59] <KittyCat> does it work for them to stream?[09:07:20] <Smirftsch3> oh and btw, I found the reason for the crackling in my project, it was depending on interpolation type in libxmp, the problem in the wav was indeed "only" overmodulation[09:07:53] <Smirftsch3> no idea, didn't try that yet, since streaming would be only of little use for me at this place[09:08:16] <Smirftsch3> so I wanted to ask first :)[09:08:26] <KittyCat> just to test that the decoders are working or not[09:08:36] <KittyCat> anything that can be streamed can be loaded into buffers[09:09:02] <Smirftsch3> guess will do so then to find out[09:50:14] *** shovel_boss has joined #openal[09:50:15] *** ChanServ sets mode: +v shovel_boss[09:50:29] <shovel_boss> MUSIC WOOOOOOOOOOOOOOOOOOOOOOOOO[10:13:23] *** Alam_Squeeze has quit IRC[10:13:48] *** Alam_Squeeze has joined #openal[10:13:48] *** ChanServ sets mode: +v Alam_Squeeze[10:19:39] *** Alam_Squeeze has quit IRC[10:24:38] *** Alam_Squeeze has joined #openal[10:24:38] *** ChanServ sets mode: +v Alam_Squeeze[10:26:35] <Smirftsch3> no, doesn't load it either, same error. I used static libs for both ogg and mpg123 to build ALURE32-static.lib, or isn't it working that way?[10:28:53] *** Alam_Squeeze has quit IRC[10:30:23] <KittyCat> Smirftsch3, are you using the code from git, or the last source release?[10:30:37] <Smirftsch3> last source release, 1.2[10:31:33] <KittyCat> I don't think that works with static linking the decoder libs[10:31:42] <KittyCat> you need to use the dlls[10:31:55] <Smirftsch3> darn.[10:32:03] <Smirftsch3> :)[10:32:05] <Smirftsch3> k, thx[10:32:34] <KittyCat> you might be able to make it work by passing whatever CFLAGS are needed to static link to those libs, but I don't know what they would be[10:32:57] <KittyCat> (passing whatever CFLAGS when building alure)[10:33:10] <Smirftsch3> currently I am in windoze only anyway, using VC[10:34:00] <Smirftsch3> just would have been nice to have everything in one dll[10:34:17] <Smirftsch3> no vital issue[10:34:32] <shovel_boss> DOES ANYONE HAVE A DUR A AND B NOTE[10:34:48] <shovel_boss> LA AND SI IN C DUR(MAJOR)[10:37:42] <Smirftsch3> oha, captain caps and his shift lock crew. I'd have a look at your piano or something...[10:40:07] <shovel_boss> Smirftsch3, this is THE piano http://prntscr.com/5lrh2b[10:41:06] <shovel_boss> the one and only[10:41:34] <shovel_boss> original petroff but on a computer[10:43:11] <Smirftsch3> :)[10:45:27] *** Alam_Squeeze has joined #openal[10:45:27] *** ChanServ sets mode: +v Alam_Squeeze[10:58:53] *** Alam_Squeeze has quit IRC[11:01:46] *** Alam_Squeeze has joined #openal[11:01:46] *** ChanServ sets mode: +v Alam_Squeeze[11:28:53] *** Alam_Squeeze has quit IRC[11:29:17] *** Alam_Squeeze has joined #openal[11:29:28] *** ChanServ sets mode: +v Alam_Squeeze[11:47:23] *** Alam_Squeeze has quit IRC[11:50:12] *** Alam_Squeeze has joined #openal[11:50:12] *** ChanServ sets mode: +v Alam_Squeeze[13:08:33] *** shovel_boss has quit IRC[13:44:36] <Smirftsch3> doesn't seem to make a difference, both alureBufferDataFromMemory and alureCreateStreamFromMemory fail with Unsupported type, even when dynamically linked. Need to try yet with ogg, but at least with mpg123. Maybe its just a problem of mpg123 which is already more than pain to build as dll in windows, but it seems to become more trouble than its worth it[13:46:49] <Smirftsch3> could it be something which could be different in latest git?[13:58:43] *** Alam_Squeeze has quit IRC[14:04:21] <Smirftsch3> what seems to be a bit strange is, that the dynamic build doesn't want to be linked against the corresponding .lib files, is this normal for alure? or is it possilble that cmake failed somehow[14:05:43] *** CapsAdmin has quit IRC[14:07:07] *** Alam_Squeeze has joined #openal[14:07:07] *** ChanServ sets mode: +v Alam_Squeeze[14:11:28] *** prophile has joined #openal[14:11:28] *** ChanServ sets mode: +v prophile[14:40:06] <Smirftsch3> well, ogg doesnt seem to work too ^^[14:44:12] <Smirftsch3> the dll provided at the page doesn't seem to do for ogg or mp3 as well, in case its compiled in there at all?[14:54:09] <Smirftsch3> has ogg support been removed in alure git?[15:14:08] *** mat^2 has joined #openal[15:14:29] *** ChanServ sets mode: +v mat^2[15:43:05] *** Alam_Squeeze has quit IRC[15:43:25] *** Alam_Squeeze has joined #openal[15:43:25] *** ChanServ sets mode: +v Alam_Squeeze[15:58:53] *** Alam_Squeeze has quit IRC[16:00:44] *** Alam_Squeeze has joined #openal[16:00:44] *** ChanServ sets mode: +v Alam_Squeeze[16:04:47] *** bjz_ has quit IRC[16:05:07] *** bjz has joined #openal[16:05:07] *** ChanServ sets mode: +v bjz[16:08:55] *** Alam_Squeeze has quit IRC[16:11:40] *** Alam_Squeeze has joined #openal[16:11:40] *** ChanServ sets mode: +v Alam_Squeeze[16:38:23] *** Alam_Squeeze has quit IRC[16:38:49] *** Alam_Squeeze has joined #openal[16:38:49] *** ChanServ sets mode: +v Alam_Squeeze[17:32:53] *** prophile has quit IRC[17:34:41] *** prophile has joined #openal[17:34:41] *** ChanServ sets mode: +v prophile[17:55:11] *** Alam_Squeeze has quit IRC[17:57:56] *** Alam_Squeeze has joined #openal[17:57:56] *** ChanServ sets mode: +v Alam_Squeeze[18:00:24] *** prophile has quit IRC[18:10:15] *** Alam_Squeeze has quit IRC[18:21:25] *** Alam_Squeeze has joined #openal[18:21:25] *** ChanServ sets mode: +v Alam_Squeeze[18:25:02] *** prophile has joined #openal[18:25:02] *** ChanServ sets mode: +v prophile[18:43:31] *** CapsAdmin has joined #openal[18:43:31] *** ChanServ sets mode: +v CapsAdmin[18:45:11] <CapsAdmin> how should i handle loop points?[18:46:50] *** marynate has quit IRC[18:49:03] <CapsAdmin> oh[18:49:03] <CapsAdmin> AL_LOOP_POINTS_SOFT[18:49:54] <CapsAdmin> i'm trying to handle the sf2 format and now i'm at the point where i need to feed the data to openal[18:49:57] <CapsAdmin> for playing midi files[18:50:24] <CapsAdmin> i'm not sure if i should just upload the entire buffer and set sample offsets and such on play and then loop points[18:50:29] <CapsAdmin> or if i should have individual sources[18:51:06] <CapsAdmin> the first one sounds more efficent but idk if it will be buggy[18:51:18] <CapsAdmin> due to openal being async (?)[20:03:30] <CapsAdmin> hmm i don't think that would work because AL_LOOP_POINTS_SOFT is for buffer and not source[20:04:07] <CapsAdmin> if it was for source i could have 1 buffer and multiple sources using it[20:12:42] <Smirftsch3> loop point for...?[20:19:54] *** CapsAdmin has quit IRC[20:20:16] *** CapsAdmin has joined #openal[20:20:16] *** ChanServ sets mode: +v CapsAdmin[20:27:35] <CapsAdmin> Smirftsch3, for samples in an sf2 file[20:27:38] <CapsAdmin> they are instrument samples[20:28:49] <Smirftsch3> mmh, ok, i don't have a clue about sf2 ^^, sorry.[20:30:52] <CapsAdmin> it stands for sound font so it's like kinda like a text a font but for sounds[20:31:17] <CapsAdmin> let's say you have a 1mb buffer of samples and some data telling you where the samples are in that 1mb buffer[20:31:38] <CapsAdmin> how would you play this in openal? would you have a single al buffer or would you create multiple for each sound?[20:33:20] <Smirftsch3> I only know about tracker music, and using libxmp for that to decode and buffer,, openal for output[20:33:58] <Smirftsch3> but I guess a single buffer sounds more logical, I think it would be hard to keep the sounds in sync[20:38:08] <CapsAdmin> hm[20:47:28] <Smirftsch3> from what I read supports modplug soundfount, not sure if sf2, but if it does, alure supports modplug, so could use it to load and openal to play[20:48:16] <CapsAdmin> it's not really that i want to listen to the results[20:48:18] <CapsAdmin> i just wanna code it[20:48:20] <Smirftsch3> although I have to admit that my luck with alure is so far kinda limited :P[20:48:30] <CapsAdmin> i'm pretty sure foobar supports sf2[20:49:35] <Smirftsch3> I suppose foobar uses some kind of lib for it also[20:56:47] <CapsAdmin> in general i think im also confusing sample position and byte position[20:56:53] <CapsAdmin> uhh[20:57:12] <CapsAdmin> AL_LOOP_POINTS take sample position but i have byte positions[21:04:44] <CapsAdmin> oh i remember now, my default format is 16 bit so from byte position it would be * 2[21:18:15] <KittyCat> CapsAdmin, openal soft can (sorta) handle sf2/midi itself[21:18:28] <CapsAdmin> oh?[21:19:16] <KittyCat> the extension is still a WIP (not finished, subject to change), but...[21:19:57] <CapsAdmin> ah[21:20:03] <KittyCat> http://repo.or.cz/w/openal-soft.git/blob/HEAD:/OpenAL32/Include/alMain.h#l47[21:20:34] <CapsAdmin> no fun :p[21:20:47] <CapsAdmin> i don't really need it i just wanted to learn the formats and such[21:21:27] <KittyCat> http://repo.or.cz/w/openal-soft.git/blob/HEAD:/Alc/midi/sf2load.c that may help[21:22:13] <CapsAdmin> thanks[21:22:18] <CapsAdmin> i had trouble finding some references[21:22:32] <CapsAdmin> i ended up finding something written in php[21:22:40] <CapsAdmin> but it didn't seem complete[21:23:49] <CapsAdmin> right now i got all the parsing out of the way, i just need to create buffers using "shdr" info[21:26:14] <KittyCat> something I've been thinking about is having some way to do shared buffers, so the smpl data can be loaded into a single chunk of memory and then separate buffer objects can reference a part of it[21:28:41] <CapsAdmin> yeah that's what i was trying to do[21:29:08] <CapsAdmin> i think i could do it if i could set loop points on the source rather than buffer[21:29:25] <CapsAdmin> but there could also be some sync issues[21:29:58] <CapsAdmin> so instead of play i would set the sample position instead[21:31:42] <KittyCat> loop points wouldn't be enough for a source to play a portion of a buffer since you need explicit stop points as well (some soundfont samples play to its end)[22:11:37] *** bjz has quit IRC[22:11:44] *** bjz_ has joined #openal[22:11:44] *** ChanServ sets mode: +v bjz_[22:31:27] *** mat^2 has quit IRC[22:35:56] *** mat^2 has joined #openal[22:35:56] *** ChanServ sets mode: +v mat^2[23:48:24] *** maxfx has joined #openal[23:48:24] *** ChanServ sets mode: +v maxfx[23:48:31] *** maxfx_ has joined #openal[23:48:31] *** ChanServ sets mode: +v maxfx_[23:49:20] *** maxfx_ has quit IRC