of course construct can easily handle it. Its just that it will be quicker and easier in Ren'Py i expect.
... a statement which may need a little explanation, particularly since I have a sneaking suspicion that Shii misunderstands the term "event-based" as applied to Construct. Sorry if you're totally clear on the concept. I'm basing my assumption on your question about keeping audio playing through several events, which I think is a really weird thing to ask if we're assuming the Construct sense of "event".
By the way, it's perfectly OK to misunderstand stuff. I myself am not all that clear on this "visual novel" concept -- I'm picturing something like an illustrated and slightly animated, linear or perhaps CYOA-style branching, story; but I almost expect to be wrong.
So, deep breath. Prepare for textdump in 3 ... 2 ... 1.5 ... 1 ...
When people say that Construct is "event-driven" or "event-based", that's a programming technical term. It means that Construct programs aren't so-called "batch programs" which run through a to-do-list and then stop. Rather, a Construct program waits for "events" (with Construct, that's often things like keypresses, mouse clicks, sprite collisions etc.) to happen and responds to them as they occur.
In other words: Instead of "Do A. Do B. Do C. Do D. If the result of D is below zero, do B again. Stop.", Construct works more like "Whenever n happens, do A. Whenever o or p happens, do B. Whenever q happens, do C.", with the implication that if n and p happen simultaneously, the Construct program will do both A and B.
This is ideally suited for the more hectic kind of game, where a lot of things may or may not be happening at any given moment (Is the monster close enough to attack the perspective character? Did any bullets just hit anything interesting? Is the player pressing any movement buttons? Is the PC moving, or perhaps falling off a cliff? Has the background music ended and needs to be restarted?), and where there are only a few different "contexts" so that usually the same event calls for the same response.
Now rewind to the top of this post, where I thought that Visual Novels are pretty much the opposite of such a game: Instead of few contexts and many possible events at any moment, such a program would have a lot of different scenes but spend most of its time waiting for one specific event per scene. Also, each scene would be a different context -- pressing [space], or whatever the canonical turn-the-page button is, should lead to scene 2 if it happens during scene 1; but pressing [space] again in scene two should probably do something other than restarting scene two.
You can still do it in Construct -- particularly the shiny new Timeline object in the latest version (0.95.5, for posterity) would make a few aspects easier, I expect -- but it's a case where all the event-oriented Construct code would probably be more complicated to both write and read than something that looks more linear, movie-script-like. (Again, I'm merely assuming that Ren'Py is such a tool. I know little more than that it exists.)