Does ‘soundnotify’ in glulx work? Or is it dodgy?
Basically I’d like to know if a sound has stopped playing without using a glulx timer to measure its duration. I think I decided a few months ago that there wasn’t any way to do this - but right now I’m thinking ‘gosh, it would help if there was’, so I’m asking here to doublecheck.
Also, if soundnotify does work, what’s a sample of I7 code showing how to use it?
I’m sure that sound notifications will work better than using the timer. I don’t think I’ve seen any I7 implementation of sound notifications, though. You could try contacting Eliuk Blau, the author of the still-unreleased DaMusix, which I believe implements notifications. The other option would be to try building it yourself, maybe by studying the I6 code for playing sounds in the Inform template code and existing extensions, alongside resources like [url=http://www.iffydoemain.org/glkdunces/summary.txt]Marnie Parker’s infglk summary[url]. Also check out Emily Short’s Glulx Entry Points.
–Erik
Thanks. I’ve already visited most of these ports of call.
I don’t think I’m ready for more of that build it yourself agony 
I did that to work out how to create new channels. Since I don’t even know the format of Inform 6 except in a monkey-see-monkey-do way, it took days for me to work out 8 lines of code that would compile. And every time I tried to get help, google took me back to that glk for dunces page. Argh!
Glulx Entry Points reminds you that ‘Currently Inform is not designed to support sound output properly across all systems.’
Some notes on DaMusix says that soundnotify doesn’t work correctly in some interpreters.
I think the last port of call will be to approach Eliuk.
Hm, maybe support for sound notification is a bit hinky. It turns out to be incredibly easy to set up a notification, but the only interpreter I could find that actually fires notifications is Windows Git (probably Windows Glulxe also works). Gargoyle and Spatterlight on OS X both fail to send a notification, as does Gargoyle on Windows–all of these return positive for the sound notification gestalt, so there is definitely some kind of failure here. (Filfre crashes with an “OLE error”, presumably on attempting to play the ogg, so I’m not sure whether it would send the notification or not).
Anyway, here’s some code for playing a sound with notification:
[code]To play (SFX - sound name) with notification:
(- PlaySoundN(ResourceIDsOfSounds–>{SFX}); -).
Include (-
[ PlaySoundN resource_ID ;
if (resource_ID == 0) return;
if (glk_gestalt(gestalt_Sound, 0)) {
glk_schannel_play_ext(
gg_foregroundchan, ! channel
resource_ID, ! resource number of sound
1, ! number of repetitions
1 ! whether to send notification (0 = no)
);
}
else {
print "[Sound effect number ", resource_ID, " here.]^";
}
];
-).
A glulx sound notification rule:
say “A sound just completed.”[/code]
–Erik
Thanks a ton for that code. Hm, looks like there’s definite hurdles in this area for the time being.
I should add that the code I posted requires Glulx Entry Points, which provides the glulx sound notification rules.
–Erik
Can you post a compiled game to the garglk issue tracker? I’d like to investigate.
Sound notifications ought to work. The only wrinkle is that they are “polled” events so they take a back seat to most other events, though you should still get them eventually.
Are you canceling the line input request in the main window prior to printing your notification text? Otherwise it will be silently suppressed.
Jeez, why can’t I get that through my thick skull? I was indeed failing to cancel line input, yet again. In other words, sound notifications do work in Gargoyle–just remember not to use them to print text to the main window without canceling line input!
Thanks Ben!
–Erik
Resurrecting this 20 month old topic…
So I’m finally testing some sound notification code, and in Gargoyle. Notifications work, but in such a way that I don’t think they’re of much use for the most obvious aims an author would put them to.
If you want to use the notification to know when to move to the next track of audio: if the player happens to be sitting and thinking, the playhead won’t move ahead, because as of the moment the notification rule is ready to go, it waits until the player next does something before firing - EG types, clicks the mouse. In a front menu section in particular, this will just lead to silence after the first track plays.
If you want to use the notification to check if audio is still playing and thus needs to be faded before the player moves into a no audio section, this is unreliable, as the notification often arrives after the program has checked whether it needs to fade or not.
I don’t know if this is the behaviour across any interpreter that can do sound, but I can’t check as Gargoyle is the only soundy one I can run on the Mac. But for developers, I just want to point out that sound notifications are important for audio work, but they’re not useful as they are. What with sound always being in real time, the notifications also need to be in real time.
Hrm. They are supposed to work in real time – that’s the point. I don’t know if that’s a problem with the Glk library, or the extension structure that passes the event on to a rule.
Ben said something about them being ‘polled’ events? But I don’t know enough about it to say whether that’s relevant.
The code I used to launch the sound was a simplified version of what’s in Massimo Stella’s Multiple Sounds extension. I might test again with Erik’s code from a few posts above, just to see if that makes any difference.
Yeah, I just tried this with Erik’s code and the notifications behaved the same way as with Massimo’s code.
Glulx Entry Points does just this to hand the event off to the rulebook:
[code]Include (-
[ HandleGlkEvent ev context abortres newcmd cmdlen ;
context = 0; ! suppress ignored warning
switch (ev–>0) {
evtype_Redraw:
if (FollowRulebook( (+glulx redrawing rules+) ) && RulebookSucceeded()) { rtrue; }
evtype_Arrange:
if (FollowRulebook( (+glulx arranging rules+) ) && RulebookSucceeded()) { rtrue; }
evtype_Timer:
if (FollowRulebook( (+glulx timed activity rules+) ) && RulebookSucceeded()) { rtrue; }
evtype_SoundNotify:
if (FollowRulebook( (+glulx sound notification rules+) ) && RulebookSucceeded()) { rtrue; }
evtype_Hyperlink:
FollowRulebook( (+glulx hyperlink rules+) );
if ( FollowRulebook( (+command-counting rules +) ) && RulebookSucceeded())
{
FollowRulebook( (+input-cancelling rules+) );
FollowRulebook( (+command-showing rules+) );
if ( FollowRulebook( (+command-pasting rules+) ) ) return 2;
}
evtype_CharInput:
if (FollowRulebook( (+glulx character input rules+) ) && RulebookSucceeded()) { rtrue; }
evtype_LineInput:
if (FollowRulebook( (+glulx line input rules+) ) && RulebookSucceeded()) { return 2; }
evtype_MouseInput:
FollowRulebook( (+glulx mouse input rules+) );
if ( FollowRulebook( (+command-counting rules +) ) && RulebookSucceeded())
{
FollowRulebook( (+input-cancelling rules+) );
FollowRulebook( (+command-showing rules+) );
if ( FollowRulebook( (+command-pasting rules+) ) ) return 2;
}
}
];
-) before “Glulx.i6t”.[/code]
There shouldn’t be any problem there…
–Erik
At some point, a year ago, I added “Write Glk sound unit test” on my todo list. It’s still there. Grn.
This looks like a bug in Gargoyle. I put together a minimal example project (attached) that plays a sound and prints out text when it gets notification that the sound is over. This works correctly in Windows Inform 7 and Windows Glulxe, but when I run it under Gargoyle the notification event doesn’t show up until I press a key. This is definitely not what it supposed to happen. (Not that that helps you much, as you’re on OSX and no other interpreter supports sound.)
I’ve entered a Gargoyle issue for this: http://code.google.com/p/garglk/issues/detail?id=204. So, to answer the original question: Glulx sound notifications aren’t dodgy, but Gargoyle’s implementation of them might be.
source.txt (807 Bytes)
Sound Notifications.gblorb (621 KB)
Thanks for clearing that up, David.