What could be blocking a sound notification attempt from reaching the Quixe parser?

I’ve implemented the bulk of the glk sound library on Bisquixe, opting to work within the established framework rather than establishing my own glk calls, because it’d be nice to have the same code work for offline and online.

The one place I’m getting stuck is with notifications.

I’ve successfully managed to mimic how notifications are sent, and I’ve put a console.log into prepare_resume in quixe.js to see what is getting passed in.

When I pass in a hyperlink, the event looks like this (and works successfully):
image

When I pass in a sound event for sound number 3, it looks like this:
image

7 corresponds to evtype_SoundNotify.

The game file I’m using is Soundtest by angstsmurf. It has rules for processing sound events:

Input handling code
Glulx input handling rule for a sound-notify-event:
	if test-running is true:
		cancel character input in the main window;
		handle test sound glk event value 1 notification glk event value 2;
		restart character input in the main window;
		the rule succeeds;
	cancel line input in the main window, preserving keystrokes;
	unless glk sound notification is supported:
		say "[bracket]This interpreter claims to not support sound notifications, so something must be wrong.[close bracket][line break]";
	let N be glk event value 2;
	if N is multinotification:
		handle unknown multichannel stopped;
	otherwise:
		let C be the chan in row N of the Table of Sound-Channels;
		say "[bracket]Sound notification: The [name of resource (glk event value 1)] finished playing on channel [N].[close bracket][paragraph break]>";
		now C is stopped;
	restart line input in the main window.

And in the IDE interpreter, we get:
[Sound notification 2 for sound resource id 3 (the AIFF).]

But it doesn’t print this in Quixe.

There have been a few places in Quixe where things like event types are hard coded. Is there something missing that needs to be added to allow these sound type events to get passed into the parser?

1 Like

Never mind, it seems like it’s project dependent and action-dependent.

If I just write a rule like this:

Glulx input handling rule for a sound-notify-event:
    play sound of weird on background;

(using the Music extension), then it works perfectly!

But if I ask it to print out, it gets mad.

Fortunately, playing one sound when another ends is the main use of this type of extension, so I might play around with the text stuff for a while, but I’m pretty close to a complete implementation of the sound glk functions!

I’m well impressed at this, and the speed you’ve put the whole thing together.

Sound notifications have been a bit wobbly in their implementation across interpreters, in my experience. Though I haven’t revisited it for a while now. For instance in Gargoyle, a game would acknowledge a notification had happened, but then not act on it until the player inputted something. In other words, if you had music playing, and the track ran out, and you wanted it to start the next track automatically (like an iPod), that next track wouldn’t start playing until the player entered their next command.

-Wade

1 Like

I think notifications in Gargoyle work as they should now. The sound implementation in Bocfel relies on them.

This used to be something that was platform-dependent, so we wrote separate notification implementations for Windows, Mac and Linux, but I think Qt takes care of it on all of them now.

3 Likes

I think this might be a potential cause of problems. I said in the other thread that the replaced VM_ReadKeyboard() in the original Soundtest is functionally the same as the echo replacement extension, but I realise now that it also sets the global stored_buffer to point to the a_buffer parameter, in order to preserve any typed text when there is a notification.

Removing all references to stored_buffer and any attempts to preserve keystrokes, i.e. storing and preloading the current input buffer, might make things simpler.