gistfile1.txt

Sep 24 04:00:44 *	jl_ ([email protected]) has joined ##zynaddsubfx
Sep 24 04:51:58 *	jl_ has quit (Ping timeout: 264 seconds)
Sep 24 05:48:40 *	dsr1204 ([email protected]) has joined ##zynaddsubfx
Sep 24 06:39:46 *	jl_ ([email protected]) has joined ##zynaddsubfx
Sep 24 06:53:05 *	jl_ has quit (Ping timeout: 248 seconds)
Sep 24 06:54:05 *	dsr1204 has quit (Quit: dsr1204)
Sep 24 07:17:00 *	jl_ ([email protected]) has joined ##zynaddsubfx
Sep 24 07:33:15 *	jl_ has quit (Ping timeout: 240 seconds)
Sep 24 16:58:11 *	dsr1204 ([email protected]) has joined ##zynaddsubfx
Sep 24 18:40:15 *	dsr1204 has quit (Quit: dsr1204)
Sep 27 11:59:36 <ssj71>	fundamental: I didn't actually say, congrats on the job! Sounds like a good one, is it in the boston area?
Sep 27 12:54:29 <fundamental>	ssj71: bedford, MA, so 20 minutes or so to being in boston
Sep 27 12:55:07 <fundamental>	it should provide the benifits of being in boston without the commute/rent headaches of being inside boston
Sep 27 12:55:21 <fundamental>	that said finding a place is more difficult than I had expected
Sep 27 12:57:02 <ssj71>	yeah, I did a remote internship for a little Boston company. They flew me out once, but then I did the rest of the summer here at home. I thought it was a cool city
Sep 27 15:31:29 *	jl_ ([email protected]) has joined ##zynaddsubfx
Sep 27 15:47:00 *	jl_ has quit (Quit: leaving)
Sep 27 15:58:33 *	jl_ ([email protected]) has joined ##zynaddsubfx
Sep 27 16:21:12 *	jl_ has quit (Ping timeout: 252 seconds)
Sep 29 11:09:37 *	jl_ ([email protected]) has joined ##zynaddsubfx
Sep 29 11:49:50 *	jl_ has quit (Ping timeout: 258 seconds)
Sep 29 13:13:59 *	ssj71 has quit (Ping timeout: 260 seconds)
Sep 29 13:14:13 *	ssj71 (c0449e6a@gateway/web/freenode/ip.192.68.158.106) has joined ##zynaddsubfx
Sep 29 15:15:52 *	jl_ ([email protected]) has joined ##zynaddsubfx
Sep 29 15:20:01 *	jl_ has quit (Ping timeout: 240 seconds)
Sep 29 16:14:18 *	jl_ ([email protected]) has joined ##zynaddsubfx
Sep 29 16:44:00 *	jl_ has quit (Ping timeout: 248 seconds)
Sep 29 19:10:58 *	jl_ ([email protected]) has joined ##zynaddsubfx
Sep 29 20:23:30 *	jl_ has quit (Ping timeout: 258 seconds)
Sep 30 03:41:46 *	trebmuh has quit (Ping timeout: 264 seconds)
Sep 30 03:54:16 *	trebmuh (~Olivier@2a01:cb11:416:ed00:f80a:1630:a7d0:b333) has joined ##zynaddsubfx
Sep 30 06:23:22 *	jl_ ([email protected]) has joined ##zynaddsubfx
Sep 30 06:24:18 <jl_>	After saving an OSC savefile, I load it into a second Master in order to compare the two Masters
Sep 30 06:24:49 <jl_>	However, since I need to dispatch the savefile to MiddleWare's ports, I thought a second MiddleWare would also be required
Sep 30 06:26:01 <jl_>	However, can't I simply call MiddleWare::updateResources() and exchange the Master?
Sep 30 06:29:04 <jl_>	fundamental: Would that exchange be allowed, and if yes, do I need to freeze anything before it?
Sep 30 06:40:55 <jl_>	bbl switching trains
Sep 30 06:41:06 <fundamental>	jl_: the exchange should be good. look at the load_xmz code
Sep 30 06:41:25 <fundamental>	and make sure no messages are being sent to a half baked master instance
Sep 30 06:41:32 <fundamental>	(other than the osc load ones)
Sep 30 06:45:16 *	jl_ has quit (Ping timeout: 258 seconds)
Sep 30 08:42:00 *	jl_ ([email protected]) has joined ##zynaddsubfx
Sep 30 08:42:26 <jl_>	back
Sep 30 08:46:55 <jl_>	btw: fundamental, from looking at Middleware's liblo calls, is it true that if a UDP client asks "/port:i\0,", zyn would reply "/port:i\0,i\042" via UDP? This would mean a client like oscprompt would behave like it has write-only-ports?
Sep 30 09:20:20 *	jl__ ([email protected]) has joined ##zynaddsubfx
Sep 30 09:22:03 *	jl_ has quit (Ping timeout: 258 seconds)
Sep 30 09:28:49 *	jl__ has quit (Ping timeout: 248 seconds)
Sep 30 10:02:47 *	jl_ ([email protected]) has joined ##zynaddsubfx
Sep 30 10:10:05 *	jl_ has quit (Ping timeout: 240 seconds)
Sep 30 10:11:10 *	trebmuh has quit (Ping timeout: 264 seconds)
Sep 30 10:22:48 *	jl_ ([email protected]) has joined ##zynaddsubfx
Sep 30 10:53:17 *	jl_ has quit (Ping timeout: 258 seconds)
Sep 30 11:31:07 *	jl_ ([email protected]) has joined ##zynaddsubfx
Sep 30 11:59:33 <jl_>	fundamental: If you have some answers to my questions above, let me know, I'll be online the next ~5 hours.
Sep 30 16:04:34 *	jl_ has quit (Ping timeout: 264 seconds)
Sep 30 17:02:18 *	dsr1204 ([email protected]) has joined ##zynaddsubfx
Sep 30 18:07:44 <fundamental>	for later copy/pasting "The messages are almost correct, '/port\0,' -> '/port\0,i\042' would be essentially what would occur allowing oscprompt to interact with ports in a read+write manner"
Sep 30 18:16:42 *	dsr1204 has quit (Quit: dsr1204)
Oct 01 05:47:43 *	dsr1204 ([email protected]) has joined ##zynaddsubfx
Oct 01 06:16:04 *	dsr1204 has quit (Quit: dsr1204)
Oct 01 07:19:25 *	johannes_2 ([email protected]) has joined ##zynaddsubfx
Oct 01 07:39:05 *	johannes_2 has quit (Quit: leaving)
Oct 01 08:47:06 *	johannes_2 ([email protected]) has joined ##zynaddsubfx
Oct 01 12:26:44 *	trebmuh (~Olivier@2a01:cb11:416:ed00:39d4:1a10:b495:9e40) has joined ##zynaddsubfx
Oct 01 12:49:12 <fundamental>	johannes_2: The messages are almost correct, '/port\0,' -> '/port\0,i\042' would be essentially what would occur allowing oscprompt to interact with ports in a read+write  manner
Oct 01 12:55:07 <johannes_2>	somehow, it would be interesting to have a possibility to let a client app (like oscprompt) infer the tree of all readable ports from a server (like zynaddsubfx)
Oct 01 12:55:25 <johannes_2>	by infer, I mean somehow share the C++ code
Oct 01 12:56:59 <johannes_2>	Though I'm not sure if there's any reason why one would need that
Oct 01 12:58:16 <johannes_2>	Anyways, fundamental, I think I asked two questions yesterday (with ~4 hours delay in between), do you see another one?
Oct 01 13:03:49 <fundamental>	you had a few questions before switching trains. I think I answered those. Then you only had the question about UDP client/oscprompt and write-only-ports which I think the recent response answered
Oct 01 13:03:53 <fundamental>	johannes_2: ^^
Oct 01 13:04:52 <johannes_2>	fundamental: I didn't receive any response from you yesterday... The connection must have been extremely bad :)
Oct 01 13:04:59 <johannes_2>	Do you still have them?
Oct 01 13:10:40 <fundamental>	07:41 < jl_> bbl switching trains
Oct 01 13:10:40 <fundamental>	07:41 < fundamental> jl_: the exchange should be good. look at the load_xmz code
Oct 01 13:10:43 <fundamental>	07:42 < fundamental> and make sure no messages are being sent to a half baked master instance
Oct 01 13:10:46 <fundamental>	07:42 < fundamental> (other than the osc load ones)
Oct 01 13:16:10 <johannes_2>	thanks, so you don't see any danger that the Middleware currently does something with the Master pointers while switching?
Oct 01 13:16:43 <johannes_2>	Ah, it can not, since it's currently doing the save...
Oct 01 13:17:00 <johannes_2>	Or at least, it's informed
Oct 01 13:17:03 <johannes_2>	Ok, getting it
Oct 01 13:22:07 <fundamental>	yeah, the threading model is a bit odd and certainly underdocumented, though there is an underlying logic
Oct 01 13:23:52 <johannes_2>	One last thing... I have been looking for a way to let MiddleWare know when the Master failed to write a savefile. I think you mentioned the way of continuing until an alert message is being sent. For some reasons, I'd prefer to let MW query master for the "last_xmz" variable (that variable is already existing)
Oct 01 13:24:32 <johannes_2>	if any load fails, I'd let zyn set last_xmz to something that won't be a filename, like "FILE_LOADING_FAILED"
Oct 01 13:25:27 <johannes_2>	I'd use the last_xmz variable even for Masters loaded from OSC files
Oct 01 13:26:51 <johannes_2>	Are you OK with using that variable like that?
Oct 01 13:40:00 <fundamental>	sure, that sounds fine to me
Oct 01 13:40:30 <fundamental>	I'd just double check the code in the FLTK GUI which consumes last_xmz in case "FILE_LOADING_FAILED" might produce unexpected behavior
Oct 01 13:55:26 <johannes_2>	ok, I'll make some tests
Oct 01 19:25:05 *	johannes_2 has quit (Ping timeout: 248 seconds)
**** ENDING LOGGING AT Mon Oct  2 09:01:18 2017

**** BEGIN LOGGING AT Wed Oct  4 06:10:43 2017

Oct 04 06:10:43 *	Now talking on ##zynaddsubfx
Oct 04 11:29:50 *	johannes_2 ([email protected]) has joined ##zynaddsubfx
Oct 04 12:05:21 *	milk ([email protected]) has joined ##zynaddsubfx
Oct 04 13:23:17 <johannes_2>	fundamental: Here ( https://github.com/zynaddsubfx/zynaddsubfx/blob/master/src/Misc/Master.cpp#L1042-L1048 ), msg_id is not increase in case of "/load-master". I'm changing the loop slightly. Is it OK if msg_id will be increased in this case?
Oct 04 13:23:28 <johannes_2>	I guess yes, since it's just a debugging counter
Oct 04 13:25:06 <johannes_2>	The same question also for the variable "events"
Oct 04 13:41:23 <johannes_2>	"if(!offline) new_master->AudioOut(outl, outr);" -> Why is this line in runOSC()? Why can't you call AudioOut after runOSC() returned false?
Oct 04 13:54:15 <johannes_2>	Probably, this is just an invariant, right?
Oct 04 13:56:08 <johannes_2>	and nvm about my first question, solved it
Oct 04 13:56:24 <johannes_2>	(the one with msg_id)
Oct 04 14:14:55 <fundamental>	johannes_2: yes to the msg_id change
Oct 04 14:15:31 <fundamental>	johannes_2: offline opperation is a bit wonkey
Oct 04 14:16:04 <fundamental>	essentially a plugin host can decide that it is not going to run the audio callback, but the event handling in AudioOut historically has been needed for the GUI to get various events
Oct 04 14:16:14 <fundamental>	so there's going to be some weird offline dependent cases
Oct 04 14:17:11 <johannes_2>	fundamental: it sounds like we'll better leave it there, then?
Oct 04 14:18:40 <johannes_2>	Btw, IIRC, you said I should test with Nio not started, and one way to achieve it would be something like a boolean variable and an if around that "Nio::masterSwap(new_master);" line?
Oct 04 14:19:12 <fundamental>	yeah, that would be an appropriate way to make testing easier
Oct 04 14:30:52 <fundamental>	I wonder what https://github.com/zynaddsubfx/zyn-fusion-issues/issues/111 would end up producing (when you consider host automation patterns)
Oct 04 14:35:39 <johannes_2>	Isn't it already doable by having the same instrument duplicatedm one wet, one dry, and both with amplitude envelopes shifted by 180° ?
Oct 04 14:37:08 <johannes_2>	This is obviously less comfortable, but if he says it would produce great sounds, he could probably create some patches to show what he means?
Oct 04 14:38:22 <johannes_2>	"s/amplitude envelope/amplitude lfo/g"
Oct 04 14:41:30 <fundamental>	if all phase randomization is disabled, yes
Oct 04 15:22:34 <johannes_2>	It's a bit strange to allow applyOscEvent() to accept "/load-master" (previously, only runOSC did). If I'd implement this, every other caller to applyOscEvent() (OutMgr, JackEngine) can potentially call "/load-master", so they all need to provide the outl and outr buffers...
Oct 04 15:23:18 <johannes_2>	In practice, I think the only one who should be allowed to call "/load-master" should be MiddleWare
Oct 04 15:24:42 <johannes_2>	fundamental: Maybe it would be better to have two functions, e.g. applyOscEvent() and applyOscEventInclLoadMaster(), where only the latter takes outl and outr parameters?
Oct 04 15:33:33 <fundamental>	johannes_2: you might need to double check that the forwarding logic works out in the end, but I'd imagine it should boil down to the two functions you mentiond
Oct 04 15:33:36 <fundamental>	*mention
Oct 04 15:34:42 <johannes_2>	ok, I'll try it out
Oct 04 15:54:40 *	johannes_2 has quit (Quit: leaving)
Oct 04 17:32:22 *	dsr1204 ([email protected]) has joined ##zynaddsubfx
Oct 04 18:44:39 *	dsr1204 has quit (Quit: dsr1204)
Oct 04 18:45:21 *	dsr1204 ([email protected]) has joined ##zynaddsubfx
Oct 04 19:10:15 *	dsr1204 has quit (Quit: dsr1204)
Oct 05 12:49:59 *	johannes_2 ([email protected]) has joined ##zynaddsubfx
Oct 05 14:26:56 *	johannes_2 has quit (Ping timeout: 246 seconds)
Oct 05 15:06:01 *	caoliver ([email protected]) has joined ##zynaddsubfx
Oct 05 15:07:18 <caoliver>	Just dropping and testing my VPN.  It seems to behave.
Oct 05 15:07:22 <caoliver>	TTYL
Oct 05 15:07:28 *	caoliver has quit (Client Quit)
**** BEGIN LOGGING AT Fri Oct  6 16:32:14 2017

Oct 06 16:32:14 *	Now talking on ##zynaddsubfx
Oct 06 17:13:22 *	johannes_2 has quit (Ping timeout: 260 seconds)
**** BEGIN LOGGING AT Fri Oct  6 20:00:06 2017

Oct 06 20:00:06 *	Now talking on ##zynaddsubfx
Oct 06 20:32:40 *	dsr1204 ([email protected]) has joined ##zynaddsubfx
Oct 06 21:39:50 *	dsr1204 has quit (Quit: dsr1204)
Oct 07 00:36:25 *	johannes_2 ([email protected]) has joined ##zynaddsubfx
Oct 07 01:39:08 *	dsr1204 ([email protected]) has joined ##zynaddsubfx
Oct 07 02:14:38 *	dsr1204 has quit (Quit: dsr1204)
**** BEGIN LOGGING AT Sat Oct  7 05:25:09 2017

Oct 07 05:25:09 *	Now talking on ##zynaddsubfx
Oct 07 09:48:40 *	johannes_2 has quit (Quit: leaving)
Oct 07 10:44:14 *	johannes_2 ([email protected]) has joined ##zynaddsubfx
Oct 07 11:04:21 <johannes_2>	I just ran my OSC savefile code through helgrind (valgrind --tool=helgrind <call>), and thousands of errors came... However, some of them are also present in the normal zynaddsubfx binary
Oct 07 11:04:37 <johannes_2>	it's mostly Thread link reading and writing
Oct 07 13:20:34 <johannes_2>	Hmm I think helgrind can not cope with this kind of parallelism. Of course, there are no locks between the threads, so a tool like helgrind might think that all accesses from two thread are in danger of happening at the same time
Oct 07 13:21:06 <johannes_2>	However, we have a message system (including things like freezing etc), which makes many simultaneous accesses impossible
**** BEGIN LOGGING AT Sat Oct  7 17:34:58 2017

Oct 07 17:34:58 *	Now talking on ##zynaddsubfx
Oct 07 17:51:45 *	johannes_2 has quit (Ping timeout: 248 seconds)
**** BEGIN LOGGING AT Sun Oct  8 02:42:05 2017

Oct 08 02:42:05 *	Now talking on ##zynaddsubfx
**** BEGIN LOGGING AT Sun Oct  8 07:02:12 2017

Oct 08 07:02:12 *	Now talking on ##zynaddsubfx
**** BEGIN LOGGING AT Sun Oct  8 07:37:36 2017

Oct 08 07:37:36 *	Now talking on ##zynaddsubfx
Oct 08 08:19:42 *	johannes_2 ([email protected]) has joined ##zynaddsubfx
Oct 08 10:08:46 *	johannes_2 has quit (Ping timeout: 255 seconds)
Oct 08 10:47:58 *	johannes_2 ([email protected]) has joined ##zynaddsubfx
Oct 08 11:17:35 *	johannes_2 has quit (Ping timeout: 248 seconds)
Oct 08 11:24:28 *	trebmuh has quit (Quit: Quitte)
Oct 08 12:01:25 *	trebmuh (~Olivier@2a01:cb11:416:ed00:8805:d382:7257:38d2) has joined ##zynaddsubfx
Oct 08 12:04:22 *	trebmuh has quit (Client Quit)
Oct 08 12:07:05 *	trebmuh (~Olivier@2a01:cb11:416:ed00:8805:d382:7257:38d2) has joined ##zynaddsubfx
Oct 08 12:16:14 *	trebmuh has quit (Quit: Parti)
Oct 08 12:18:21 *	trebmuh (~Olivier@2a01:cb11:416:ed00:8805:d382:7257:38d2) has joined ##zynaddsubfx
Oct 08 12:41:57 *	johannes_2 ([email protected]) has joined ##zynaddsubfx
Oct 08 13:07:57 <fundamental>	it doesn't sound like there's a race condition, though that ends up being all in the details
Oct 08 13:08:11 <fundamental>	and I would expect switchMaster to look quite similar to loadMaster
Oct 08 13:08:13 <fundamental>	johannes_2: ^^
Oct 08 13:23:02 <johannes_2>	fundamental: if pointers are not atomic, MiddleWare could change the half of the master poitner value, and then the RT thread (which is still running) could read both halves of the master and jump to an invalid address
Oct 08 13:23:16 <johannes_2>	that was why I'd expect a racing condition
Oct 08 13:23:55 <johannes_2>	so I think MiddleWare is not allowed to call the master-changed-callback
Oct 08 13:29:27 <fundamental>	pointer swaps are atomic on all x86 platforms (not neccessarily the case with arm)
Oct 08 13:29:50 <fundamental>	the master pointer in middleware is *not* the pointer that the NIO engine uses
Oct 08 13:30:03 <fundamental>	nor, is the master instance aware of said pointer
Oct 08 14:15:58 <johannes_2>	fundamental: exactly, but doesn't the zynaddsubfx lv2 plugin use the pointer from this callback?
Oct 08 14:17:01 *	caoliver ([email protected]) has joined ##zynaddsubfx
Oct 08 14:17:02 *	caoliver has quit (Client Quit)
Oct 08 14:31:22 *	caoliver ([email protected]) has joined ##zynaddsubfx
Oct 08 14:54:22 <fundamental>	hurrah, I finally have internet at the new house/rental
Oct 08 14:54:58 <fundamental>	johannes_2: yes. I am pretty rough when it comes to the details of the threading guarentees for the plugin version
Oct 08 15:04:29 <caoliver>	I actually got quite used to the lack for the terrible few months.
Oct 08 15:04:55 <caoliver>	BTW: hexchat now runs in a firejail on my 24/7 box.
Oct 08 15:05:18 <caoliver>	So as long as I remember where xpra has put it, I win.
Oct 08 15:06:01 *	caoliver thinks xpra/firejail should have a name to socket convention for these things.  ssh/yasbox/547 isn't terribly mnemonic.
Oct 08 15:07:04 <caoliver>	I might work up a curl/nginx+lua hack for that sort of thing though.
Oct 08 15:08:47 <caoliver>	BTW: if I didn't say so before, I read the press releases and I can say we're (my current gig) doing new tech for line-of-sight radio assessment using drones.
Oct 08 15:09:22 <fundamental>	drone-tech is a cool area to be working with
Oct 08 15:09:26 *	caoliver ([email protected]) has left ##zynaddsubfx ("Leaving")
Oct 08 15:09:36 *	caoliver ([email protected]) has joined ##zynaddsubfx
Oct 08 15:09:58 <caoliver>	We have a lawyer in Traverse City who actually has that as a specialty.
Oct 08 15:10:16 <caoliver>	Who'd have thought drone law specialization was a thing.
Oct 08 15:11:23 <fundamental>	it was pretty enevitiable once the FAA had to step in to regulate them
Oct 08 15:11:48 <caoliver>	Sadly, they're using conventional choppers as a metaphor.
Oct 08 15:12:12 <caoliver>	I.e. you can't have the pilot and the instrument guy be the same individual as it stands.
Oct 08 15:13:10 <caoliver>	It makes sense given that a real chopper is a bitch to fly.  (I've a long time friend who's a commercial pilot and has logs a few hours in a chopper.)
Oct 08 15:13:31 <caoliver>	A quad or hex rotor is VERY stable by comparison.
Oct 08 15:14:00 <fundamental>	I wonder what regulations will eventually settle for the first person drone racing communities
--
Sep 01 13:01:49 <dsheeler>	what's PRNG state?
Sep 01 13:02:16 <fundamental>	In the past 'rand()' was used to create random numbers in zyn
Sep 01 13:02:30 <fundamental>	the problem is that it made tests produce different results on different platforms
Sep 01 13:02:52 <fundamental>	so in Util.cpp I implemented a psuedo-random number generator which was the same on all platforms
Sep 01 13:03:11 <fundamental>	bbl
Sep 01 13:03:14 <dsheeler>	neat.  
Sep 01 13:24:10 <DrSegfault>	fundamental: what was the name again of the pattern where you used MiddleWareImpl only in the cpp file to save compile time for files including MiddleWare.h?
Sep 01 13:39:48 <rgareus>	DrSegfault: from what you describe, perhaps you're looking for "forward declaration"?
Sep 01 13:42:07 <DrSegfault>	rgareus: IIRC the design pattern name was more specific
Sep 01 14:17:54 *	JeppeZapp[m] has quit (Remote host closed the connection)
Sep 01 14:17:58 *	pdesaulniers[m] has quit (Read error: Connection reset by peer)
Sep 01 14:24:41 *	pdesaulniers[m] (pdesaulnie@gateway/shell/matrix.org/x-hswytptususnkota) has joined ##zynaddsubfx
Sep 01 14:25:39 *	pdesaulniers[m] has quit (Remote host closed the connection)
Sep 01 14:35:53 *	pdesaulniers[m] (pdesaulnie@gateway/shell/matrix.org/x-yjhymkeqwfzffvwp) has joined ##zynaddsubfx
Sep 01 14:44:41 *	JeppeZapp[m] (jzappmatri@gateway/shell/matrix.org/x-waphtbsdhczimazy) has joined ##zynaddsubfx
Sep 01 16:20:47 <dsheeler>	hmmm, found another ADnote problem.  if a voice is more complicated than a sine, it has a discontinuity.  I think it's because the phase is reset 
Sep 01 16:40:27 <dsheeler>	actually, it can be a sine and still have problem
Sep 01 17:58:23 <fundamental>	DrSegfault: PIMPL
Sep 01 17:58:32 <fundamental>	private implementation something something
Sep 01 17:59:33 <fundamental>	"Pointer to IMPLmentation"
Sep 01 18:00:06 <fundamental>	dsheeler: oscillator phase randomization?
Sep 01 18:00:10 <fundamental>	that might do it
Sep 01 18:00:41 <dsheeler>	where does that happen?
Sep 01 18:02:19 <fundamental>	if you follow OscillGen::get() down ~2 levels you should see it
Sep 01 18:03:32 <fundamental>	line 1088
Sep 01 18:04:20 <fundamental>	if the two oscillators have the same PRNG initial state and the number of harmonics is the same, then the phase randomization should be the same
Sep 01 18:15:10 *	Notify: Kripton is online (FreeNode).
Sep 01 18:20:11 <dsheeler>	here's a thing.  I commented out the call to get in legatonote and I still get pops for at least one instrument i tried.  should that work, to not call that in legatonote?
Sep 01 18:22:10 <DrSegfault>	PIMPL, that was it, thanks
Sep 01 18:22:39 <dsheeler>	it eliminates pops for some instruments, but not all
Sep 01 18:27:08 <fundamental>	dsheeler: newrandseed() for the OscilSmp might be shifting some values around enough that at least phases are different
Sep 01 18:27:40 <fundamental>	and that happens in initparameters as well as the legato specific code
Sep 01 18:27:45 <fundamental>	so, that's one possibility
Sep 01 18:31:18 <fundamental>	dsheeler: here's one trick I'll recommend for diagnosing the problem
Sep 01 18:32:29 <dsheeler>	actually, i've commented out newrandseed() as well
Sep 01 18:32:35 <dsheeler>	forgot to say that
Sep 01 18:32:47 <fundamental>	make the left channel always output the old and right the output of the new
Sep 01 18:32:52 <fundamental>	that way it's clear what's different
Sep 01 18:38:45 <dsheeler>	how would i do that?  you mean in a recording?
Sep 01 18:43:23 <dsheeler>	or you mean in code?
Sep 01 19:21:01 <dsheeler>	somehow some pops involve panning.  with panning get pops, without panning no pops
Sep 01 20:18:06 <dsheeler>	found out why panning.  when inspecting the panning parameter, if it's 0 (as like an invalid value, except 0 is valid for a parameter), then panning variable is set to something random.  so if panning is all the way to the left (0 parameter value), it gets changed to random
Sep 01 20:20:18 <dsheeler>	this should affect every ADnote with voice panned all the way to left because it's in the constructor as well as in legatonote, i think
Sep 01 20:20:48 <dsheeler>	but bottom line is I think I fixed everything about legato pops
Sep 01 22:56:26 <fundamental>	"fixed everything" - Excellent :)
Sep 01 23:03:57 <dsheeler>	haha.  right.  everything problem I could find would be a better way to put it 
**** BEGIN LOGGING AT Sun Sep  2 01:02:12 2018

Sep 02 01:02:12 *	Now talking on ##zynaddsubfx
Sep 02 01:02:12 *	Topic for ##zynaddsubfx is: The ZynAddSubFX open source musical synthesizer http://zynaddsubfx.sf.net
Sep 02 01:02:12 *	Topic for ##zynaddsubfx set by [email protected] at Fri Apr 13 08:08:21 2018
Sep 02 03:40:30 <dsheeler>	Patch and explanation is up on the bug report
Sep 02 07:10:49 <DrSegfault>	fundamental: I'm having an error where the zyn master pointer changed somehow, but MiddleWare is still using an old Master pointer. It only happens when I'm having two zyn plugins loaded at the same time. IIRC there should be no such issues like globals or thread-unsafety in zyn, right?
Sep 02 07:11:05 <DrSegfault>	I guess some users have alrady had 2 LV2 plugins at the same time without issues?
Sep 02 07:32:35 <DrSegfault>	Ignore please, I'm seeing this happens even with one plugin.
Sep 02 07:35:33 <DrSegfault>	the MiddleWare thread tries to access a MiddleWareImpl::master, but this master is already deleted by the same thread
Sep 02 07:47:51 <DrSegfault>	No, now I think it only happens with 2 plugins at the same time, again
Sep 02 08:13:13 <fundamental>	DrSegfault: as long as there is one and only one Middleware thread and one and only one audio generation thread you should not have that issue
Sep 02 08:13:21 <fundamental>	it sounds like you have more than one Middleware thread
Sep 02 08:13:52 <fundamental>	(there can be multiple threads, but max one per plugin for each audio/middleware)
Sep 02 08:25:55 <DrSegfault>	I think the thread count is right
Sep 02 08:26:25 <DrSegfault>	What I'm seeing is that MW tries to access a Master that it has deleted, due to a received "/free:sb" from the backend
Sep 02 08:27:19 <DrSegfault>	As I'm not loading any parts, this can only come from a "/load-master" the Master received
Sep 02 08:28:01 <DrSegfault>	And MW can only send "/load-master" after it has switched to the new master
Sep 02 08:28:18 <DrSegfault>	So what happens is impossible
Sep 02 08:29:14 <DrSegfault>	The debug output even does show that MiddleWare updated its Master before sending "/load-master"
Sep 02 08:42:06 <fundamental>	I'm not sure then
Sep 02 08:42:17 <fundamental>	are you somehow using the same ringbuffer for multiple instances or something?
Sep 02 08:42:32 <DrSegfault>	fundamental: I'm having something: https://github.com/zynaddsubfx/zynaddsubfx/blob/master/src/Misc/Master.cpp#L770-L771 -> Is it bad if both of those pointers are equal here?
Sep 02 08:43:17 <fundamental>	DrSegfault: yes
Sep 02 08:48:12 <DrSegfault>	This sounds like the newly created master already reads messages, while it should wait for the old one to read "/load-master"?
Sep 02 08:49:02 <DrSegfault>	like it "steels" the messages
Sep 02 08:49:18 <fundamental>	the newly created master should not read any *realtime* messages until the swap in the rt thread
Sep 02 08:49:36 <fundamental>	it can read non-realtime messages before that point though
Sep 02 08:49:42 <fundamental>	IIRC
Sep 02 09:12:30 <DrSegfault>	OK, I've done considerable mistakes
Sep 02 09:17:08 <DrSegfault>	Here's my new plan of what a plugin must do, in order:
Sep 02 09:17:32 <DrSegfault>	1. call mw->messageAnywhere("/load_xmz", ...)
Sep 02 09:17:32 <DrSegfault>	2. wait for mw's next tick to be done, so the "/load_xmz" is known to be at Master
Sep 02 09:17:32 <DrSegfault>	3. run master.runOsc() (with the still old master)
Sep 02 09:17:32 <DrSegfault>	4. Sleep, until mw has sent an UI callback "/load_xmz", so we know whether if worked
Sep 02 09:17:55 <DrSegfault>	Can you please check it, fundamental ?
Sep 02 09:19:35 <fundamental>	why are you calling 3?
Sep 02 09:19:41 <fundamental>	that should be called automatically in the audio thread
Sep 02 09:23:22 <DrSegfault>	you mean by LMMS, when it wants to get the next buffer for playback?
Sep 02 09:23:44 <DrSegfault>	The problem is, I'm not sure if LMMS will ask for a new buffer while loading a file :-/
Sep 02 09:24:29 <DrSegfault>	I could make tries
Sep 02 09:25:08 <fundamental>	that sounds like an exceptionally strange design choice on the part of LMMS
Sep 02 09:25:19 <fundamental>	it should always be trying to get new audio
Sep 02 09:25:56 <DrSegfault>	For steps 1+2, I'll be using a simple atomic to find out whether a heartbeat has been done. Is this OK?
Sep 02 09:27:17 <fundamental>	if the heartbeat is dead, then it should be safe to do what you're doing
Sep 02 09:27:23 <fundamental>	but all in the same thread
Sep 02 09:27:26 <fundamental>	so no sleep at 4
Sep 02 09:29:26 <DrSegfault>	ah yes, I'm seeing it, no sleep is required
Sep 02 09:33:23 <DrSegfault>	fundamental: Step 2 can also be omitted, assuming/hoping LMMS will fetch audio continously ?
Sep 02 09:36:19 <fundamental>	step two should not be needed as there should be a middleware thread running in the background
Sep 02 09:47:00 <rgareus>	dsheeler: looking at your patch,  https://sourceforge.net/p/zynaddsubfx/bugs/_discuss/thread/311bf367/9359/attachment/zyn_legato_fix.patch , I find your style of commening out code, odd. 
Sep 02 09:47:12 <rgareus>	dsheeler: the patch isn't very readable.
Sep 02 09:47:33 <rgareus>	also since this is git, why not simply remove the code? (it's easy to revert)
Sep 02 09:50:46 <rgareus>	dsheeler: anyway. they're nice fixes. no more clicks! YAY!
Sep 02 09:54:33 <DrSegfault>	fundamental: The case where Master receives "/load-master" with new_master == this_master comes from here: https://github.com/zynaddsubfx/zynaddsubfx/blob/master/src/Misc/MiddleWare.cpp#L699-L701
Sep 02 10:25:24 <dsheeler>	rgareus: I agree, the commented stuff should not be that way. I need to fix those parts, but not sure the right way, yet.
Sep 02 10:28:26 <dsheeler>	fundamental, did you see what was going on in those sections?
Sep 02 10:34:05 <dsheeler>	Well, just looked at your comments.  "a number of patches intentionally use this feature..."  what feature do you mean?
Sep 02 10:56:14 <dsheeler>	rgareus: was your only issue with the patch those comments?
Sep 02 11:01:00 <rgareus>	dsheeler: I only looke at the patch in a text-editor, so yes.   -- I did not compile zyn and only listend to your .wav examples
Sep 02 11:02:10 <rgareus>	another nitpick: it's also .diff (a .patch would have a commit-message header and work directly with `git am`)
Sep 02 11:02:54 <dsheeler>	ahh, haha, thanks.  how do i make a proper patch with git?
Sep 02 11:03:18 <rgareus>	e.g. compare  https://github.com/Ardour/ardour/commit/67f733bb  to  https://github.com/Ardour/ardour/commit/67f733bb.diff  to  https://github.com/Ardour/ardour/commit/67f733bb.patch
Sep 02 15:48:54 *	DrSegfault has quit (Ping timeout: 252 seconds)
Sep 02 15:50:22 *	DrSegfault ([email protected]) has joined ##zynaddsubfx
Sep 02 16:13:42 <fundamental>	dsheeler: phase randomness
Sep 02 16:15:41 <fundamental>	DrSegfault: I guess at least there is a warning
Sep 02 16:15:50 <fundamental>	why is LMMS having the plugin run offline?
Sep 02 16:20:59 <fundamental>	DrSegfault: it should be possible to fix that logic, though somewhat hairy to think through the possible cases
Sep 02 16:24:46 <dsheeler>	fundamental: I was talking about these lines 55-58: https://github.com/zynaddsubfx/zynaddsubfx/blob/6f8a61f6ee74316e471495f040660318a339d0c7/src/Synth/ADnote.cpp#L55
Sep 02 16:25:30 <dsheeler>	That's not phase randomness, but panning randomness, but it's also a bug, I think
Sep 02 16:26:57 <fundamental>	err, yes panning randomness
Sep 02 16:26:59 <fundamental>	my bad
Sep 02 16:27:10 <dsheeler>	oh, okay :)
Sep 02 16:27:21 <dsheeler>	but does it work correctly? 
Sep 02 16:27:21 <fundamental>	the panning resonance is intentional and was documented in the FLTK tooltips from ages ago
Sep 02 16:27:47 <fundamental>	the logic should be if(phase == 0) phase = random_phase(); else phase = phase
Sep 02 16:27:57 <fundamental>	which seemed to be the logic in the lines that you commented out
Sep 02 16:28:16 <dsheeler>	wait, you said phase again :P
Sep 02 16:28:50 <dsheeler>	did you mean panning?
Sep 02 16:29:25 <fundamental>	yes
Sep 02 16:29:28 <fundamental>	mental glitch :p
Sep 02 16:29:34 <dsheeler>	lol np
Sep 02 16:30:12 <dsheeler>	ok, so panning == 0 is like panning to the extreme left.  see what i mean?
Sep 02 16:30:24 <dsheeler>	why would you randomize that?
Sep 02 16:30:39 <fundamental>	because it's a "special value"
Sep 02 16:31:00 <fundamental>	which I find dumb as you'd expect there to be a "randomize phase control" rather than a magical value
Sep 02 16:31:07 <fundamental>	but that's how it was historically implemented
Sep 02 16:31:18 <dsheeler>	ok.  that seems crazy to me, so i can't believe it's on purpose 
Sep 02 16:31:29 <fundamental>	it's one of those things that in the 3.1.0 parameter remapping should be resolved
Sep 02 16:32:08 <fundamental>	from the FLTK tooltips: "Panning (leftmost is Random)"
Sep 02 16:32:30 <dsheeler>	haha!  what if you want leftmost panning???
Sep 02 16:33:14 <fundamental>	then you want value "1"
Sep 02 16:33:31 <fundamental>	it's absurd, but it's the behavior that was built in pre 2004
Sep 02 16:33:43 <dsheeler>	ok.  as long as you think it's absurd, too :)
Sep 02 16:33:52 <fundamental>	yeah, no disagreement there
Sep 02 16:34:08 <fundamental>	I'm just trying to avoid changing the sounds of old patches
Sep 02 16:34:16 <dsheeler>	totally get it now
Sep 02 16:34:19 <fundamental>	unintentionally at least
Sep 02 16:34:53 <fundamental>	every so often there will be a "Well, that DSP is totally and utterly wrong" moment
Sep 02 16:35:24 <fundamental>	which should just get fixed, but this is a "That parameter mapping is beyond idiotic, but I don't want to make the new mapping quite yet" moment
Sep 02 16:38:29 <dsheeler>	i think changing to random panning for legato was causing pops.  how about i restore it everywhere but in legato?  it was in three places, like ADnote constructor, initparameters and computecurrentparameters, I think 
Sep 02 16:39:27 <fundamental>	so, you still want it, you just want it to be deterministic
Sep 02 16:39:41 <fundamental>	which was my suggestion with providing Add Synth a random seed
Sep 02 16:39:51 <fundamental>	so legato would work like 
Sep 02 16:40:03 <fundamental>	1. Add Synth (new seed)
Sep 02 16:40:13 <fundamental>	2. Add Synth legato (seed from 1)
Sep 02 16:40:31 <fundamental>	3. Add Synth legato (seed from 1 copied from 2)
Sep 02 16:40:33 <fundamental>	...
Sep 02 16:40:50 <fundamental>	N. Add Synth legato (still using a seed from 1 via copies)
Sep 02 16:41:18 <fundamental>	so you get a 'random' panning value, but the same 'random' panning value across different legato notes
Sep 02 16:42:27 <fundamental>	the same seed could be supplied to stuff like the Oscil objects so random phasing is the same
Sep 02 16:43:00 <dsheeler>	ahh, think i get that now
Sep 02 16:43:46 <fundamental>	it's a roundabout solution, but it fits some of the strange logic behind how legato was initially implmented
Sep 02 16:44:00 <fundamental>	(aka a really fun to play with hack job)
Sep 02 17:25:54 <DrSegfault>	fundamental: As I did not set offline explicitly to true, this can only mean that the audio thread did not request new samples for 200ms or longer?
Sep 02 17:26:17 <fundamental>	DrSegfault: that should be correct
Sep 02 17:27:31 <DrSegfault>	OK, I'll make some checks tomorrow
Sep 02 18:20:28 <fundamental>	it looks like the initial sketch of those moog ladder filters isn't too hard http://fundamental-code.com/tmp/2018-10-moog-ladder.png
Sep 03 05:26:29 <dsheeler>	fundamental: how should this random seed stuff be implemented?  Add to synthParameter class? 
Sep 03 09:27:20 *	trebmuh has quit (Remote host closed the connection)
Sep 03 09:27:56 *	trebmuh (~Olivier@2a01:cb11:416:ed00:dcfc:e90:d51c:c386) has joined ##zynaddsubfx
Sep 03 10:46:35 *	pdesaulniers ([email protected]) has joined ##zynaddsubfx
Sep 03 12:00:00 <DrSegfault>	fundamental: The 200ms timeout explains why it isn't working with valgrind only. Still, in this case, I think a slow Master should not lead to a program exit?
Sep 03 12:41:26 *	day0 ([email protected]) has joined ##zynaddsubfx
Sep 03 14:16:54 <fundamental>	dsheeler: that would be a reasonable place since it affects multiple engines
Sep 03 14:17:00 <fundamental>	DrSegfault: ah, that could explain it
Sep 03 14:49:52 <dsheeler>	fundamental: I'm a little foggy on the big picture about legato.  Like, I have been thinking legato is transforming the old note to the new note, 
Sep 03 14:50:10 <dsheeler>	but really it's creating a new note, right?
Sep 03 15:04:20 *	day0 has quit (Quit: WeeChat 2.2)
Sep 03 15:28:59 <DrSegfault>	fundamental: LMMS uses instruments for previewing files, those only call GetAudioOutSamples() when you preview a file, so the Master is offline for a very long time. It will then do a load, meaning that it will be offline at that time...
Sep 03 15:31:37 <DrSegfault>	Maybe, for this case, I'll add a bool parameter to "tick()", which won't call the master->runOSC() ( https://github.com/zynaddsubfx/zynaddsubfx/blob/master/src/Misc/MiddleWare.cpp#L701 ) if it's false... Will anything not work if that master->runOSC() is not called?
Sep 03 15:35:29 <fundamental>	dsheeler: more or less, yes
Sep 03 15:36:30 <fundamental>	DrSegfault: it will get 'weird' if you have nothing pumping values throught the OSC ringbuffers
Sep 03 17:01:12 *	pdesaulniers has quit (Remote host closed the connection)
Sep 04 12:52:55 *	ssj71 (c0449e6a@gateway/web/cgi-irc/kiwiirc.com/ip.192.68.158.106) has joined ##zynaddsubfx
Sep 04 16:59:07 *	day0 ([email protected]) has joined ##zynaddsubfx
Sep 04 18:12:42 <dsheeler>	fundamental: can you explain how the random seed thing will work?  
Sep 04 18:13:42 <dsheeler>	like is that prng() thing acting on gobal data?
Sep 04 18:21:54 <fundamental>	dsheeler: prng() acts on global data, but it does so by running (global_state = prng_r(global_state))
Sep 04 18:22:14 <fundamental>	so if you capture a random seed you can draw pseudo-random samples from it using the prng_r function
Sep 04 18:24:34 <dsheeler>	what do you mean "capture"?
Sep 04 18:25:17 <dsheeler>	this is hard for me to wrap my head around.  
Sep 04 18:28:26 <dsheeler>	oh, wait
Sep 04 18:31:38 <dsheeler>	you mean call prng_r directly?
Sep 04 18:44:37 <fundamental>	yep
Sep 04 18:44:57 <fundamental>	so, you would store a random seed into the synth object
Sep 04 18:45:13 <fundamental>	then when you evaluated a random number you would have something like a member function which would:
Sep 04 18:45:33 <fundamental>	1. member_prng_state = prng_r(member_prng_state)
Sep 04 18:45:46 <fundamental>	2. convert_to_what_you_want(member_prng_state)
Sep 04 18:45:57 <fundamental>	3. return the result of 2
Sep 04 18:53:43 <dsheeler>	do i store the original random seed in synth to pass to a legato? 
Sep 04 18:54:04 <dsheeler>	or do I pass the current state?
Sep 04 18:57:15 <fundamental>	original
Sep 04 18:57:39 <fundamental>	so for a synth object you'd likely want to store "initial seed" and "current prng state"
--
**** BEGIN LOGGING AT Mon Jul  8 07:02:13 2019

Jul 08 07:02:13 *	Now talking on ##zynaddsubfx
Jul 08 07:02:13 *	Topic for ##zynaddsubfx is: The ZynAddSubFX open source musical synthesizer http://zynaddsubfx.sf.net
Jul 08 07:02:13 *	Topic for ##zynaddsubfx set by [email protected] at Fri Apr 13 08:08:21 2018
Jul 08 08:30:02 <fundamental>	michiboo[m]: did you watch the video discussing pre-trigger and post-trigger buffers?
Jul 08 08:38:07 <michiboo[m]>	Do you mean the introduction to triggering video?? If so I did watch it, so I so include a small display for pre-trigger and post-trigger data?
Jul 08 08:38:39 <michiboo[m]>	should*
Jul 08 08:42:10 <fundamental>	having a pre-trigger and post-trigger concept is a first step towards being able to have multiple waveforms triggered synchronously
Jul 08 08:42:25 <fundamental>	and IIRC you expressed interest in displaying multiple waveforms at once
Jul 08 08:50:27 <michiboo[m]>	Yes, but doesn't multi-waveform trigger mean that if one of the waveform being watched is triggered, all other waveform will be triggered? how does pre-trigger and post-trigger concept come into play?
Jul 08 08:51:17 <fundamental>	consider watch points (1) and (2). Let's say they're both active and you're waiting for a trigger on either
Jul 08 08:51:33 <fundamental>	you could see (1) no trigger (2) no trigger
Jul 08 08:51:42 <fundamental>	(1) no trigger (2) trigger
Jul 08 08:52:09 <fundamental>	in that case you already saw the samples from (1) and with the current approach, discarded them since the watchpoint was not triggered
Jul 08 08:52:26 <fundamental>	so then you get samples from (2), but you get delayed samples from (1) meaning they're not in sync
Jul 08 08:53:35 <fundamental>	having pre-trigger data from (1) and (2) makes it simple to say "(2) has triggered, so use data from this frame from (1)" without having to explicitly know if the synth reads (1) then (2) or (2) then (1)
Jul 08 08:56:06 <michiboo[m]>	Yes, but wouldn't it be when (2) trigger, (1) will trigger as well, and vice versa. hmm  then we would need to create a extra buffer for pre-trigger data?
Jul 08 08:56:58 <fundamental>	correct, when (2) triggers, then (1) should trigger on the same sample. This functionality isn't possible with the current design though.
Jul 08 09:05:11 <michiboo[m]>	why tho? I thought we could check all other watchpoint with the similar ID and trigger it, for e.g. /part0/kit0/padpars/noteout" and "/part0/kit0/padpars/noteout1" , we could check for the string "/part0/kit0/padpars/noteout" is a substring of ID if so we will trigger it
Jul 08 09:05:38 <michiboo[m]>	why tho? I thought we could check all other watchpoint with the similar ID and trigger it, for e.g. /part0/kit0/padpars/noteout" and "/part0/kit0/padpars/noteout1" , we could check for the string "/part0/kit0/padpars/noteout" is a substring of ID if so we will trigger it
Jul 08 09:11:47 <fundamental>	the time that you trigger it can be after you've seen the data
Jul 08 09:15:55 <fundamental>	http://fundamental-code.com/tmp/timeline.png
Jul 08 09:16:09 <fundamental>	consider CPU time going from left to right
Jul 08 09:16:29 <fundamental>	upwards spikes are when the data is handed to watchpoint (1)
Jul 08 09:16:35 <fundamental>	downward spikes are when the data is handed to watchpoint (2)
Jul 08 09:16:39 <fundamental>	T=trigger
Jul 08 09:16:45 <fundamental>	C=capture
Jul 08 09:16:46 <fundamental>	D=done
Jul 08 09:17:16 <fundamental>	the image shows the current behavior if (2) triggers and it puts (1) into the triggered/collecting state
Jul 08 09:17:41 <fundamental>	you'll note that the frames where (1) gets data and where (2) gets data are shifted by one
Jul 08 09:18:01 <fundamental>	which would result in a offset getting added making the trigger non-synchronous
Jul 08 09:18:35 <fundamental>	dsheeler: are you going to be interested in the summit?
Jul 08 09:20:49 <michiboo[m]>	ahh I see, thanks for the explanation
Jul 08 09:44:41 <michiboo[m]>	hmm I am thinking to remove the drop box since if we display multiple waveform there is no need for them any more
Jul 08 09:45:04 <fundamental>	I wouldn't neccessarily display all waveforms all the time
Jul 08 09:45:12 <fundamental>	that would be information overload
Jul 08 09:56:04 <michiboo[m]>	ahh okay I guess for now I will display 2 waveform, hmm I have question about front end,  once I put 2 widgets within a group widget, the onExtern function of the children widget stop working. Is this a normal behavior?
Jul 08 09:58:39 <fundamental>	if there's widget A with children B and C; and B.extern depends on A.extern and C.extern depends on A.extern; then A.extern should still update B&C. If not, then it's likely a bug in zest
Jul 08 10:30:34 <michiboo[m]>	hmmm it is mostly a bug, because once I remove the group widget (parent) it work perfectly
Jul 08 10:30:43 <michiboo[m]>	likely*
Jul 08 10:30:58 <michiboo[m]>	I will try to think a way around this
Jul 08 17:50:59 <dsheeler>	fundamental: Nah, I'm not that interested in the summit.
Jul 09 11:04:43 *	friedolino ([email protected]) has joined ##zynaddsubfx
Jul 09 16:03:53 *	friedolino has quit (Remote host closed the connection)
Jul 10 12:10:16 *	friedolino ([email protected]) has joined ##zynaddsubfx
Jul 10 13:19:57 *	friedolino has quit (Remote host closed the connection)
Jul 10 13:20:11 *	friedolino ([email protected]) has joined ##zynaddsubfx
Jul 10 14:14:43 *	Disconnected (Connection reset by peer).
**** ENDING LOGGING AT Wed Jul 10 14:14:43 2019

**** BEGIN LOGGING AT Wed Jul 10 14:15:09 2019

Jul 10 14:15:09 *	Now talking on ##zynaddsubfx
Jul 10 14:15:09 *	Topic for ##zynaddsubfx is: The ZynAddSubFX open source musical synthesizer http://zynaddsubfx.sf.net
Jul 10 14:15:09 *	Topic for ##zynaddsubfx set by [email protected] at Fri Apr 13 08:08:21 2018
Jul 10 14:15:09 *	Notify: fundamental is online (FreeNode).
Jul 10 14:15:09 *	Notify: Zharf is online (FreeNode).
Jul 10 14:15:09 *	Notify: Kripton is online (FreeNode).
Jul 10 14:15:10 *	Notify: rgareus is online (FreeNode).
Jul 10 14:37:45 *	Disconnected (Connection reset by peer).
**** ENDING LOGGING AT Wed Jul 10 14:37:45 2019

**** BEGIN LOGGING AT Wed Jul 10 14:38:08 2019

Jul 10 14:38:08 *	Now talking on ##zynaddsubfx
Jul 10 14:38:08 *	Topic for ##zynaddsubfx is: The ZynAddSubFX open source musical synthesizer http://zynaddsubfx.sf.net
Jul 10 14:38:08 *	Topic for ##zynaddsubfx set by [email protected] at Fri Apr 13 08:08:21 2018
Jul 10 14:38:08 *	Notify: fundamental is online (FreeNode).
Jul 10 14:38:08 *	Notify: Zharf is online (FreeNode).
Jul 10 14:38:08 *	Notify: Kripton is online (FreeNode).
Jul 10 14:38:09 *	Notify: rgareus is online (FreeNode).
Jul 10 15:49:27 *	friedolino has quit (Remote host closed the connection)
Jul 10 15:49:52 *	friedolino ([email protected]) has joined ##zynaddsubfx
Jul 10 15:52:54 *	friedolino has quit (Remote host closed the connection)
Jul 10 15:53:13 *	friedolino ([email protected]) has joined ##zynaddsubfx
Jul 10 16:48:44 *	friedolino has quit (Remote host closed the connection)
Jul 11 14:59:25 *	friedolino ([email protected]) has joined ##zynaddsubfx
Jul 11 15:00:14 *	friedolino has quit (Remote host closed the connection)
Jul 11 15:00:29 *	friedolino ([email protected]) has joined ##zynaddsubfx
Jul 11 15:43:48 *	friedolino has quit (Remote host closed the connection)
Jul 12 08:56:13 *	friedolino ([email protected]) has joined ##zynaddsubfx
Jul 12 11:23:08 *	friedolino has quit (Ping timeout: 252 seconds)
Jul 12 11:37:03 *	friedolino ([email protected]) has joined ##zynaddsubfx
Jul 12 11:40:03 *	friedolino has quit (Remote host closed the connection)
Jul 12 14:04:55 <DrSegfault>	IIRC zyn's audio must be processed continously, because you'll get a timeout error from MiddleWare otherwise... Was that correct?
Jul 12 14:05:33 <DrSegfault>	If that's true, a DAW can't just load 50 zyn instruments and keep any audio processing down for that time span, right?
Jul 12 14:06:01 <DrSegfault>	It rather needs to keep processing while steadily loading the new instruments
Jul 12 16:12:37 *	friedolino ([email protected]) has joined ##zynaddsubfx
Jul 12 17:55:12 *	friedolino has quit (Remote host closed the connection)
Jul 12 20:05:50 <fundamental>	DrSegfault: not correct
Jul 12 20:05:58 <fundamental>	the original design made that assumption
Jul 12 20:06:06 <fundamental>	but a variety of plugin hosts violated it
Jul 12 20:06:17 <fundamental>	then the heartbeat algorithm was created for plugin modes
Jul 12 20:15:50 <fundamental>	when the audio generation does not have a heartbeat, then middleware takes over for handling RT OSC events
Jul 13 04:05:49 *	friedolino ([email protected]) has joined ##zynaddsubfx
Jul 13 08:46:01 <DrSegfault>	fundamental: When I implemented my OSC plugin for zyn (like ~ 1 yr ago), I did changes to MiddleWare.cpp. Without those changes, LMMS almost always failed when loading larger projects with multiple zyns: https://github.com/zynaddsubfx/zynaddsubfx/commit/eb6e192f362b52542027fc2f8efb696a3456108f#diff-1d896367cef8581b2f6bc784702f6246
Jul 13 08:46:13 <DrSegfault>	I now changed it back temporarily, and it somehow works
Jul 13 08:46:38 <DrSegfault>	Did you change the behaviour in the last year?
Jul 13 08:49:11 <DrSegfault>	I don't see any changes in MiddleWare.cpp explaining the difference
Jul 13 10:11:12 <DrSegfault>	ahh, it's still present: bool zyn::Master::applyOscEvent(const char*, float*, float*, bool, bool, zyn::DataObj&, int): Zusicherung »new_master != this_master« nicht erfüllt.
Jul 13 13:25:10 <DrSegfault>	Sorry btw for posting German, it means "Assertion 'new_master != this_master' not fulfilled".
Jul 13 13:25:50 <DrSegfault>	friedolino: btw, np with the patch, no need to hurry, I just thought you already updated it and I somehow missed it
Jul 13 13:35:40 <friedolino>	DrSegfault: ok. thats good. Im quite busy preparing an going on a family vacation trip for the next weeks.
Jul 13 15:57:56 *	friedolino has quit (Remote host closed the connection)
Jul 13 16:49:22 *	Notify: oneman is online (FreeNode).
Jul 13 16:50:07 *	Notify: oneman is offline (FreeNode).
Jul 14 05:35:01 *	friedolino ([email protected]) has joined ##zynaddsubfx
Jul 14 15:16:25 *	friedolino has quit (Remote host closed the connection)
Jul 15 01:50:37 *	zeograd has quit (*.net *.split)
Jul 15 01:53:36 *	zeograd ([email protected]) has joined ##zynaddsubfx
Jul 15 02:16:12 *	Notify: Zharf is online (FreeNode).
Jul 15 06:03:01 *	michiboo[m] sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/PFglXSnGNjJcatTnLrlDnMRt >
Jul 15 06:04:12 <michiboo[m]>	Is there any step I am missing beside changing synth->buffersize from 256 to 64?
Jul 15 06:41:40 *	friedolino ([email protected]) has joined ##zynaddsubfx
Jul 15 07:21:47 <fundamental>	michiboo[m]: Some of the tests assume that the buffer length is long. e.g. testDefaults() is checking outL[255] is set to a known value
Jul 15 07:22:04 <fundamental>	so, for the add note test it's basically assumed
Jul 15 07:22:23 <fundamental>	for another test it should be easier to vary buffer size if you want to validate behavior with respect to that
Jul 15 07:33:23 <michiboo[m]>	I see thanks!
Jul 15 08:22:43 <fundamental>	DrSegfault: that's a pretty lax heartbeat threshold
Jul 15 08:23:02 <fundamental>	that means that the GUI can freeze for 10 seconds if the given host doesn't run audio
Jul 15 11:25:28 *	Notify: Zharf is online (FreeNode).
Jul 15 14:27:56 <DrSegfault>	I know, but those 10 seconds were required because otherwise, LMMS crashed while loading large projects...
Jul 15 14:29:41 <DrSegfault>	fundamental: Doesn't that proof that you'll get a timeout crash from MiddleWare if you don't process audio continously?
Jul 15 14:39:18 <fundamental>	it implies it, but the design should work perfectly fine with the reasonable timeout
Jul 15 14:50:06 <DrSegfault>	So this is a bug in zyn or my plugin code?
Jul 15 14:54:08 <fundamental>	your observation is inconsistent with my expectation, where that issue lies I don't know
Jul 15 15:02:36 <DrSegfault>	Does it help if I reconstruct the crash, finding out what leads to it? Maybe we can provide a fix then.
Jul 15 15:06:00 <fundamental>	likely
Jul 15 18:25:43 *	friedolino has quit (Remote host closed the connection)
Jul 16 10:18:17 *	friedolino ([email protected]) has joined ##zynaddsubfx
Jul 16 11:07:19 <DrSegfault>	anyone here who has the logs from the last 2 years and can grep it for "new_master" (without those quotes) ?
Jul 16 11:09:52 <fundamental>	DrSegfault: my logs are not complete, but new_master isn't turning up anything on my newer hexchat (as opposed to xchat) logs for this channel
Jul 16 11:11:58 <DrSegfault>	looking at the users online now, I guess no one of them was online in 2018 except dsheeler
Jul 16 11:23:08 <dsheeler>	DrSegfault: https://gist.github.com/dsheeler/a6652ff88f6547a38cbea0acd09656b6
Jul 16 11:35:15 <caoliver>	I think I'm done with all the C parts of MIDI mangler.
Jul 16 11:36:42 <caoliver>	Well for the daemon.
Jul 16 12:18:07 <DrSegfault>	dsheeler: Thanks! Can you please show a bit more context around the first two lines? maybe +- 100 lines around it?
Jul 16 12:18:21 <DrSegfault>	grep -C 100 ...