 |
DreamLight Director Talisman
|
 |
Managing Sound Lingo Practices with Director
|
|
|
Date: Jan. 31, 2002 SystemMacintosh 9500 G3, 368MB RAM, MacOS 9.0.4, Director 8.5.1 DescriptionThere are some Sound bugs in Director 8.5.1 that break code written in Director 7.0.2 as well as exhibit some internal inconsistencies. The following code that worked fine in D7: on exitFrame me the volume of sound 1 = 255 sound fadeIn 1, 5 * 60 puppetSound 1, "Background" end No longer works in D8.5.1. I know you can use the new style of "queue" & "play" but I had a few D7 Shockwave projects that stopped working when user's upgraded to Shockwave 8. My investigations of the problem also show some internal inconsistencies in Director 8.5.1's handling of sound when using fadeIn. Steps to reproduce1) Open a new movie in D7.0.2 2) Import a sound named "Background" 3) Set the sound to loop in the cast member properties 4) Put the following item into the watcher. the volume of sound 1 5) Attach the following script to frame 1 on exitFrame me the volume of sound 1 = 255 sound fadeIn 1, 5 * 60 puppetSound 1, "Background" end 6) Attach the following script to frame 5 on exitFrame go to the frame end 7) Run the movie, listen and watch. You will hear the sound fade in over the course of 5 seconds.
8) Save the movie, quit D7 and then open the movie in D8.5.1 9) Put the following two items into the watcher: Sound(1).volume 10) Run the movie... You'll hear nothing.
11) Now comment out the puppetSound line in the script and run again. You'll now see the volume of sound fade up from 0 to 255, but Sound(1).volume will remain at 0. 12) Now in the message window enter the following: the volume of sound 1 = 128 You'll see Sound(1).volume and the volume of sound 1 both go to 128. It looks like Director wants them both to be tied together, as they should be, but in some instances they tend to diverge... 13) Change the fadeIn line as follows and run the movie again: sound(1).fadeIn( 5 * 60 ) You'll notice you still have the problem of "the volume of sound" fading in but "sound(1).volume" not fading in. You'll also notice the fade is much faster, since it now is using milliseconds. 14) Now edit the line as follows and run again: fadeIn( sound(1), 5 * 60 ) and it will also be fast. Sound(1).fadeIn() uses milliseconds (using the new sound objects)
This is very much confused in the documentation, which states on page 171:
but then on page 469:
15) Now edit the script as follows and run again on exitFrame the volume of sound 1 = 255 puppetSound 1, "Background" sound fadeIn 1, 5 * 60 end This time you'll see both "sound(1).volume" and "the volume of sound 1" fade in from 0 to 255, as they should, but you'll also hear an annoying pop as the sound starts, full volume, before being faded in, this is why we always used to start the fadeIn before we puppeted the sound, in previous versions of Director. 16) Now edit the script to use the new sound objects as follows and run again on exitFrame
sound(1).volume = 255
sound(1).fadeIn( 5 * 1000 )
sound(1).queue( member("Background") )
sound(1).play()
end
And it works. So it looks like the new sound objects and syntax work as expected but older code using "sound fadeIn" from D7.0.2 may not work. This normally isn't a problem for new projects since they can be rewritten, but older projects running under the new Shockwave may not function as they did in Shockwave 7... Thanks,
Date: Oct. 31, 2001 It looks like the long standing sound looping bug that used to prevent sounds from looping properly in the last frame of the score has been FIXED in D7.0.2! This bug had been hanging around in many previous versions of Director, up to and including D6. I’m glad to finally be able to say good bye to it! -MikeS
Date: Aug. 31, 2001 I have seen a problem with Director (haven't tested it in D8) adding a pop to the beginning of a sound cast member. It puts the pop right into the sound data itself which can be seen if the sound is then brought out to a sound editing program (like SoundEdit or Peak) and viewed. If I recall correctly, it only happened if I had copied and pasted sounds right into Director's cast. They would sound fine until you saved the movie, then you'd get a pop at the beginning of the sounds. It may have also happened when importing SoundEdit formatted files. I think it may have been a problem with how Director translated from the SoundEdit format to whatever internal format it uses for storing sounds these days. At the time, I was copying sound directly from SoundEdit on the Mac. The workaround I found was simple enough. If the sounds were instead exported from SoundEdit as AIFF files and then imported into Director, they would stay fine and no pop would be added. -MikeS
Date Sep. 15, 2000 Here's some more info on the percentPlayed problem... If I set the soundDevice to QT3Mix I get better results than either DirectSound or MacroMix. But since I'm not really using QuickTime video anywhere in the project, I'd rather not make the users install QuickTime only for audio processing on the PC. I've started trying changing some settings in MacroMix to see if there is any impact. Here are steps to repro 1) Create an SWA member named "swaSound" 2) Put this script in frame 5 on exitFrame global gDebugList gDebugList = [] play Member( "swaSound" ) end 3) Put this script in frame 6 on exitFrame
global gDebugList
percent = Member( "swaSound" ).percentPlayed
if percent < 100 then
gDebugList.append( percent )
go to the frame
else
put gDebugList
end if
end
4) Set the tempo to 10 fps 5) Run it under D7.0.2 MacOS9.0.4 and I get nice smooth results where no numbers repeat. (other than some extra zeros at the beginning while the sound starts) -- [0.0000, 0.0000, 0.0000, 0.1554, 0.7837, 1.4931, 2.1958, 2.9052, 3.6079, 4.3173, 5.0199, 5.7293, 6.3509, 7.0603, 11.2965, 11.9992, 12.7086, 13.4112, 14.1206, 14.7490, 15.4516, 16.1610, 16.8637, 17.5731, 18.2757, 18.9851, 19.6067, 21.3363, 22.0390, 22.7484, 23.4510, 26.3563, 27.0589, 27.7683, 28.4710, 29.4168, 30.1195, 30.7478, 31.6870, 32.3964, 33.0990, 33.8084, 34.4368, 35.1394, 35.8488, 36.5515, 37.2609, 37.9635, 38.6730, 39.3756, 40.0850, 41.4160, 42.1254, 42.8281, 43.5375, 44.2401, 44.9495, 45.6522, 46.3548, 47.0643, 47.6926, 48.3952, 49.2600, 49.9695, 50.6721, 51.3004, 52.0031, 52.7125, 53.4152, 54.1246, 54.8272, 55.5366, 56.1650, 56.8676, 57.5770, 58.2797, 59.4553, 60.1647, 60.8673, 61.5767, 62.2794, 62.9888, 63.6915, 64.4009, 65.0292, 65.7319, 66.4413, 67.1439, 67.8533, 68.5560, 69.3397, 70.0491, 70.7518, 71.3801, 72.0895, 72.7922, 73.5016, 74.2042, 74.9136, 75.5352, 76.2446, 76.9473, 77.6567, 78.3593, 79.5417, 80.2443, 80.8727, 81.5753, 82.2847, 82.9874, 83.6968, 84.3995, 85.1089, 85.7372, 86.4399, 87.1493, 87.8519, 88.5613, 89.2640, 89.9734, 90.6017, 91.3044, 92.0138, 92.7164, 93.4191, 94.5204, 95.2298, 95.9324, 96.6351, 97.3445, 98.0471, 98.7566, 99.4592] 6) When I then run it here under D7.0.2 Win98 with the soundDevice set to DirectSound, I get the repeating numbers like this. -- [0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 0.0000, 1.8039, 1.8039, 1.8039, 3.5065, 3.5065, 5.2091, 5.2091, 5.2091, 6.8982, 6.8982, 8.5872, 8.5872, 8.5872, 10.2763, 10.2763, 11.9721, 11.9721, 13.6544, 13.6544, 13.6544, 15.3435, 15.3435, 16.8907, 16.8907, 16.8907, 18.7217, 18.7217, 20.4107, 20.4107, 20.4107, 22.0998, 22.0998, 23.7956, 23.7956, 25.4779, 25.4779, 27.1670, 27.1670, 27.1670, 28.8561, 28.8561, 30.5451, 30.5451, 30.5451, 32.2342, 32.2342, 33.9300, 33.9300, 33.9300, 35.4705, 35.4705, 37.3014, 37.3014, 37.3014, 38.9905, 38.9905, 40.6796, 40.6796, 40.6796, 42.3686, 42.3686, 44.0577, 44.0577, 44.0577, 45.7535, 45.7535, 47.4358, 47.4358, 47.4358, 49.1249, 49.1249, 50.8140, 50.8140, 50.8140, 52.5031, 52.5031, 54.1921, 54.1921, 54.1921, 55.8880, 55.8880, 57.4284, 57.4284, 57.4284, 59.2593, 59.2593, 60.8065, 60.8065, 60.8065, 62.6375, 62.6375, 64.3265, 64.3265, 64.3265, 66.0156, 66.0156, 67.7047, 67.7047, 67.7047, 69.3938, 69.3938, 70.9409, 70.9409, 70.9409, 72.7719, 72.7719, 74.4610, 74.4610, 74.4610, 76.1433, 76.1433, 77.8459, 77.8459, 77.8459, 79.5282, 79.5282, 81.2172, 81.2172, 82.7644, 82.7644, 82.7644, 84.5954, 84.5954, 86.2845, 86.2845, 86.2845, 87.9735, 87.9735, 89.6626, 89.6626, 89.6626, 91.2098, 91.2098, 93.0407, 93.0407, 93.0407, 94.5879, 94.5879, 96.4189, 96.4189, 96.4189, 98.1080, 98.1080, 99.7970, 99.7970, 99.7970] 7) Then set the soundDevice to "QT3Mix" and run again, and I get this. -- [0.0000, 0.0000, 0.0000, 0.6081, 0.6081, 1.8377, 2.4458, 3.0606, 3.6754, 4.2835, 4.8983, 5.5131, 6.1279, 6.7360, 7.3508, 8.5737, 9.1885, 9.8034, 10.2087, 10.8236, 11.4316, 12.0464, 13.2693, 13.8842, 14.4990, 15.1138, 15.7219, 16.3367, 16.9515, 17.5596, 18.1744, 18.7892, 20.0121, 20.4175, 21.0323, 21.6471, 22.2619, 23.4848, 24.0997, 24.7077, 25.3225, 25.9374, 26.5454, 27.1602, 28.3899, 28.9980, 29.6128, 30.2276, 30.6330, 31.2478, 32.4707, 33.0855, 33.6936, 34.3084, 34.9232, 35.5380, 36.1461, 36.7609, 37.3757, 37.9838, 39.2135, 39.8215, 40.4363, 40.8417, 41.4565, 42.0714, 42.6862, 43.9091, 44.5239, 45.1320, 45.7468, 46.3616, 46.9697, 47.5845, 48.1993, 48.8141, 50.0370, 50.6518, 51.0572, 51.6720, 52.8949, 53.5097, 54.1178, 54.7326, 55.3475, 56.5703, 57.1852, 57.8000, 58.4080, 59.0229, 59.6377, 60.2458, 61.2660, 61.8808, 62.4956, 63.1037, 64.3333, 64.9481, 65.5562, 66.1710, 66.7858, 67.3939, 68.0087, 68.6235, 69.2316, 69.8464, 71.0761, 71.4814, 72.0963, 73.3192, 73.9340, 74.5420, 75.1569, 76.3798, 76.9946, 77.6094, 78.2242, 78.8323, 79.4471, 80.0619, 80.6700, 81.6902, 82.3050, 82.9198, 83.5279, 84.1427, 84.7575, 85.9804, 86.5952, 87.2101, 87.8181, 88.4330, 89.0478, 89.6558, 90.2707, 90.8855, 91.9057, 92.5138, 93.1286, 93.7434, 94.3582, 94.9663, 96.1959, 96.8040, 97.4188, 98.0336, 98.6417, 99.2565] Anyone else notice this problem with percentPlayed, or a way around it (other than using QT3Mix since I don't need QuickTime elsewhere)?
Thanks,
Date: Sep. 15, 2000 Hello, Has anyone noticed any problems using percentPlayed on the PC? I'm working on the PC version of Quipples and have run into a strange problem. SWA percentPlayed is not updating fast enough. As a test I had my code that's following the progress of playing SWA audio build a list of the values returned by percentPlayed. On the Mac, each call to percentPlayed returns a unique value based on how far along the audio has played, as expected, but on the PC it keeps returning the same value a few times in a row, then jumps up a bit and returns that value, etc. Here's an output example: Mac results on a short phrase: -- [3.8316, 7.6632, 11.0004, 15.3264, 19.6112, 24.3904, 28.2220, 33.0011, 37.3271, 42.5595, 46.8855, 50.7171, 55.4963, 58.8335, 62.6651, 67.4443, 71.2759, 75.5607, 79.8867, 84.1715, 88.4975, 92.7823, 95.6663, 99.9922] Win Results on a short phrase: -- [0.0000, 0.0000, 0.0000, 0.0000, 18.4185, 18.4185, 18.4185, 18.4185, 38.0796, 38.0796, 38.0796, 38.0796, 56.3520, 56.3520, 56.3520, 56.3520, 74.8436, 74.8436, 74.8436, 92.8967, 92.8967, 92.8967, 92.8967] It seems the percentPlayed is not keeping up with the audio playback in the PC. Running under D7.0.2 Win98. Under D7.0.2 MacOS9.0.4 it's fine. If anyone has run into this already and knows a solution to get more accurate results from percentPlayed, please email (or cc) me directly so I'll get it before waiting for the digest. Otherwise, I'll keep on investigating and post what I find... -MikeS
Oct. 16, 1997 Loosing Loopbacks:I want to thank Buzz for helping me track down the problem of losing loopbacks when burning Shockwave movies. He was able to duplicate the problem using our burned shockwave. He traced it to a problem in Director 6.0 that has been fixed in Director 6.0.1. Simply reburning the movies in Director 6.0.1 alleviates the problem. Sinking Volume:I have also retested the volume issue in Director 6.0.1 / Plug-in 6.0.1 RC3 and it still exists. This may not be a bug, but it is useful to be aware of. As recommended by Buzz and others, you should use 16bit/22.050kHz as your source files in Director when planning to use Shockwave Audio compression on the movie. This not only affects the quality of the sound but the volume as well. Using anything lower than that results in a drop of volume relative to how much lower the sound's resolution is. 8bit/11kHz sounds will playback lower than 16/22kHz. You can test this quickly by burning a movie that contains 8bit/11kHz sounds using SWA compression and then playing both the .dir and .dcr files in Netscape. The .dir file will play louder than the .dcr file. Then upsample the sound yourself to 16bit/22.050kHz in SoundEdit, import the new one into the move and reburn with the same compression settings. Now both the .dir and .dcr will play with similar volumes. And your ending file size will be virtually unchanged. Anything lower than 11kHz will really drop the volume significantly, as well as sounding like chipmunks on some low end PC's with sound cards/drivers that can't handle low sampling rates. If you upsample the original low-res sounds yourself in SoundEdit, they retain their volume. In a future version of Director it may be possible for Macromedia to allow Shockwave's pre-upsample before compression to duplicate SoundEdit's upsampling to avoid this volume drop. Is that possible MM? PC Chipmunks:We had run into the chipmunk problem before and quickly realized that it has nothing to do with Shockwave or Director and is simply another fact of life in the low end PC world. For a sample of this effect, try playing DreamLight Verttice on-line on a low end PC. You'll get chipmunk sounds. Verttice was created well before Shockwave, we used 5kHz sounds to keep the overall movie size low enough for single-floppy distribution. Since Verttice was originally developed for the Mac, I didn't worry about PC chipmunks. When I ever get some free time, I'll update Verttice with upsampled sounds as well as creating a PC download version. It's one of many things on my to-do list... ;-) [Update 8/25/00: I have finally gotten around to updating DreamLight Verttice for Windows check it out!] 16Bits/22.050kHz:So, if you have an older movie that used low sampling rates and you wish to burn them into Shockwave movies using audio compression you should first upsample all sounds yourself in SoundEdit 16 to 16bits/22.050kHz. Then burn the movie with compression set as desired in the Xtras->Shockwave Audio Settings menu. This way your sounds will retain their full volume upon Shockwave playback without impacting the final file size significantly. Thanks,-MikeS
Oct. 13, 1997 DescriptionIf a movie that contains low resolution sounds is compressed as a Shockwave movie the volume of the sounds is drastically lowered upon playback under the D6.0.1 plug-in. Steps
Go back and try the same experiment with the sound as a 22kHz sound and it should play back the same volume as both a .DIR and .DCR. The problem only appears to surface with sounds that are low resolution. -MikeS
Oct. 10, 1997 >I need to puppetsound a loop in background through different movies. It's >really impossible to make a unique movie, for this project, but my client >does want a unique background sound for the whole project. Simply puppet the looping sound in a sound channel that is not being used for anything else. Then when you switch movies it will keep right on playing since it remains in memory... puppetsound 3, "myBackgroundSound" Just make sure the sound has proper loop points set in SoundEdit 16 for a seamless loop. Then verify that looping is turned on in the cast member properties. In the above sample I've used sound channel 3 assuming that you may already be using channels 1 & 2 for other purposes. -MikeS
Oct. 10, 1997 >Has anyone else experienced this? (Screeching distortion on sounds) >Any ideas for a solution? Are you playing multiple sounds at the time? Once we had a similar problem with some specific sounds that were played together with other sounds. In our case, I went back to the original 22k sounds and resampled them down to 11k again. It worked. I'm not sure why. Maybe one of them had been partially corrupted? I'm not sure if it was happening on the Mac or Windows. I think it may have been only happening on the Windows machines so I'm not sure if this is related to what you're experiencing.
Hope they help.
Oct. 10, 1997 Relative addressing locally does not work using normal Internet syntax... swURL="../websect/audio/mysound.swa" The above will work while on-line but will not work locally even if everything is in the dswmedia folder. For local relative addressing to work it must be rewritten with Director relative syntax like this... swURL="@::websect:audio:mysound.swa" Note: You could use forward slashes, but using the colons helps distinguish this from normal Internet syntax. Using the Director relative address syntax will work both locally and on-line. There is an in depth discussion of SWA local addressing on the DreamLight SoundStrip page. -MikeS
Sep. 29, 1997 Description:I'm finishing up a new streaming Shockwave audio player and am getting incorrect error messages from the D6 plug-in. Steps:
Can anyone else verify what errors are generated when the sound file name is incorrect? (Buzz verified that this problem exists and will not be getting fixed in the near future. Seems to be a problem with the Plug-in API?) Environment:Tested in D6.0 on a Macintosh 9500 MaxPower MP400+ 240MB RAM running MacOS 7.6.1 Thanks,-MikeS
Sep. 12, 1997 Hi John, >fwiw, it's still good practice not to loop in the final frame of a movie >because of the additional chores that must be done in the last frame of a >movie. True, but not really relevant to the sound looping bug itself. The fact that Director does other things in the last frame may indeed slow it down a bit but should NOT stop a looping sound. That is a bug, plain and simple. >(The first and final frames, across all versions, have had "am I really >starting/ending?" tests there, and looping in the final frames is a bit >slower than looping on internal frames. Any sprite further out in the Score >will no longer mark that desired frame as the final frame, and so you won't >incur those testing costs.) When Authoring, a developer should not need to treat any particular frame of the score any differently than any other frame since it is not presented that way by any of the documentation or the user interface. If they must, then it is a problem in Director's underlying implementation. As such, I would suggest changing the Score window somehow to visually distinguish the first and last frame. Perhaps colorize the first and last frame. This would also need to be THOROUGHLY discussed in the Director documentation which it is not... though I have been told that the corrections I posted for the "Learning Lingo" manual are being incorporated so there is still hope! ;-) JT recently asked what new features to give Lingo. I'd respond by saying to re-evaluate many of these [SDF]s. It's dissapointing to keep hearing that "it's been that way ever since...". That may be true, but that does not make it right... ;-) -MikeS PS John, I'm not trying to argue with you. I really do appreciate your help and all the hard work you guys do. I'm just trying to help make Director better... better than it has EVER been... I've been using it (and loving it) since it was called "VideoWorks 1.0" ;-)
Sep. 10, 1997 The Last Frame sound looping bug that I had reported in D4 and D5 is still present in D6... Steps to reproduce:
Add anything else after frame 10 in the score and now the sound will work fine. ;-) -MikeS
Date: Aug. 5, 1997 >I'm programming with Director 5.0.1 for Windows and I'd like to know if >there's any way of changing the volume of a sound played with >puppetSound, to different levels. I found "the volume of..." but it only >works out for the sound in a channel and also "the soundLevel" but it >does not work under Windows, just for MAC. You can set the volume of sound whichChannel. This controls an entire sound channel rather than a particular sound. We use a multichannel approach. We run two ambiant sound channels at a low level. We then use two audio tracks so that two characters can converse and even interrupt each other. We top it all off with a single FX channel. By using separate channels for separate types of sound we can more easily control the volume of at least each type of sound. Here's the corrected example from the Learning Lingo Corrections. The example in the manual was too messed up to be of any use.
on playThunder whichChannel
set oldVolume = the volume of sound whichChannel
set the volume of sound whichChannel = 255
puppetSound whichChannel, "thunder"
updateStage
repeat while soundBusy( whichChannel )
nothing
end repeat
set the volume of sound whichChannel = oldVolume
end playThunder
This handler first saves the current volume of a user specified sound channel. It then sets that channel's volume to the maximum of 255. It plays the thunder sound in the specified channel and when done returns the volume of the channel to its original value. The repeat loop allows the sound to finish before the sound level is returned to its original value. Please note that this does not effect the overall soundLevel of the machine itself. If that is set to 0, then you still won't hear anything. But the example the way it was originally written (if it was written correctly) would have raised the volume of ALL sounds playing, not just the thunder as they set out to do in the text... Note that unless you had already lowered any of the sound channels, this handler will have no apparent effect since every sound channel actually defaults to 255. ;-) If you convert your audio to digital video you can then use the volume of sprite command to control it individually. However this then limits overlapping sounds on Windows. Both the soundLevel and the volume of sound should work under both Mac and Windows, not just Mac. -MikeS
Date: Jul. 10, 1997 In case anyone out there is wondering why we use manager objects rather than directly using puppetSounds, here is another example. Our SoundManager object controls a SoundChannel object for each real sound channel in actual use. This way we issue simple commands to the SoundManager. The SoundManager and SoundChannel managers handle all the details... In this example we have ambiant sounds crossfade from one sound to another as the user leaves one room and enters another.
on ambiantSound me, whichSound, priority
global gMac
if NOT gMac then exit
if voidP( priority ) then set priority to 0
if stringP( whichSound ) then -- prepare to play the sound
if NOT ( busy( getAt( myChannels, myAmbChannel))¬
OR busy(getAt( myChannels, myAmbChannel + 1)) ) then
fadeSoundIn( getAt( myChannels, myAmbChannel), whichSound, priority )
else -- at least one is busy so we need a cross fade
if NOT busy( getAt( myChannels, myAmbChannel + 1) ) then
--put "Channel 1 busy, channel 2 not"
set inChannel to myAmbChannel + 1
set outChannel to myAmbChannel
else if NOT busy( getAt( myChannels, myAmbChannel) ) then
--put "Channel 2 busy, channel 1 not"
set inChannel to myAmbChannel
set outChannel to myAmbChannel + 1
else
--put "BOTH AMBIANT SOUND CHANNELS BUSY"
set ticks1 to the myStartTicks of getAt( myChannels, myAmbChannel )
set ticks2 to the myStartTicks of getAt( myChannels, myAmbChannel + 1 )
if ticks1 > ticks2 then --use channel 1 it's older, fading
set inChannel to myAmbChannel
set outChannel to myAmbChannel + 1
else --use channel 2 it's sound is older
set inChannel to myAmbChannel + 1
set outChannel to myAmbChannel
end if
end if
crossFade( me, whichSound, inChannel, outChannel, priority )
end if
else if whichSound = 0 then -- kill the ambiant sounds.
fadeSoundOut( getAt( myChannels, myAmbChannel ) )
fadeSoundOut( getAt( myChannels, myAmbChannel + 1 ) )
end if
end ambiantSound
First we test to be sure we're on a Mac. If not we bail. We only enable these dual ambiant soundtracks on the Mac because using too many sound channels on the PC was causing trouble on some low end machines with odd sound cards and drivers... We use a priority system so that the SoundChannel objects know which sounds can be cut short if necessary. For instance, vocals are the highest priority if they are immediate instructions. If they are simple chatter and bickering between the main characters, they are lower priority and may be cut short if necessary... This enables the characters to interact in a more lively manner... First we see if both of our ambiant sound channels are free...if they are free we simply fade in the sound into the first ambiant SoundChannel object. Otherwise we need to see if at least one is free... If so we set the inChannel to the free channel and the out channel to the busy one. If they are both busy, we then check to see which one has the older sound, the one that started first is the oldest and that is the one we step on since it is already in the process of fading out. (the only instance that two are active at once is during a cross fade) We then initiate the crossFade... This little method enabled us to have nice ambiant sounds softly transition as the user explores their 3D virutal surroundings. The SoundManager also controls other SoundChannel objects for use as effects sounds and vocal channels for the characters.... -MikeS
Date: Jul. 9, 1997 >I've tried that but it doesn't make any difference. I'm using a combination >of score sounds and puppetsounds and they both seem to have the same effect. >If I watch the memory inspector the memory gets taken up in the Cast & Score >section but only gets released if I click on the Purge button, which I can't >get to via lingo. -- >I've witnessed this behavior before also. In one project I had some >looped background sound files (300k) which switched every minute or >two. Sure enough, every time it switched the memory inspector jumped by >300k. We could NOT find a way to purge the memory from lingo. (I even >made a handler which stepped through all the cast members and unloaded >everything!) > >I suspect (for no good reason) that it has something to do with >contiguous free bytes. (Mearly a theory on my part...) > >In my case, the leak was very slow and would cause the projector to >freeze after running for 3 or 4 hours. > There is a [SDF] in the puppetSound in D4/D5/Win where sounds that are puppeted are NEVER released unless you actually issue a puppetSound channel, 0 to break the link to the sound before puppeting another sound into the channel. If you acidently puppet another sound into the same channel before clearing it out with the puppetSound channel, 0 first, then the first sound is forever locked in RAM... until the projector quits! This only happens under Windows, D4/D5/Mac would release the sounds as expected and the puppetsound channel, 0 was not necessary. I wrote the DreamLight RAMLight while tracking down this very [SDF] which was crashing the windows versions of a hybrid CD-ROM we finished a while ago. Full details should be in the archives. >Unfortunatly, I found it after the fact. Therefore, to avoid tracking >down each puppetSound instance only to add a puppetSound chnlNum, 0, why >couldn't I add a handler in my movie (or linked cast) like: > > on puppetSound chnl, name > puppetSound chnl, 0 > puppetSound chnl, name > end puppetSound > >I've tested it and it seems to work, but I'm looking for any feedback. >Am I overlooking something? It seems to easy a solution. That is close to the solution we used last year. We had our sound manager object create channel objects that controled each sound channel. This enabled us to do fancy cross fades and other neat things with the audio. When we wanted to play a sound we would pass it to the channel manager instance of a particular sound chanel. Before that channel manager puppeted the sound however, it would test if it were running under Windows and if so it would puppetSound channel, 0. OOPS!!! Upon a little closer examination I noticed that you used the keyword "puppetSound" for your own handler name. That's a no-no... That probably won't work the way you expect. You need to make up your own handler name. > > on puppetSound chnl, name > puppetSound chnl, 0 > puppetSound chnl, name > end puppetSound > Something like this would be better...
on pcSafePuppetSound chnl, name puppetSound chnl, 0 puppetSound chnl, name end pcSafePuppetSound --- Below are a few code fragments that we used in our SoundManager/SoundChannel objects when we isolated the [SDF]...
on doPuppetSound me, whichSound
global gTheMovieMan, gTestMode, gMac
set whichCast to the number of cast whichSound
if whichCast > 0 then
loadCast( gTheMovieMan, whichCast )
if NOT gMac then puppetsound( mySoundChannel, 0 )
-- break link to prior cast for PC...
puppetSound( mySoundChannel, whichCast )
else
if gTestMode then
Alert ¬
"SoundChannel/doPuppetSound:Can't find sound castmember:" && whichSound
end if
end if
end doPuppetSound
-- doPuppetSound (all one word) is one of the methods of our SoundChannel object. We instance one of these manager objects for each channel we intend to use... It performs many other fuctions such as cross fades, playing lists of sounds etc... loadCast is a method of the MovieManager object which performs a memory test to see if the intended castmember will fit in RAM. It purges memory if necessary until the sound fits into RAM. If it fails it aborts the movie with a graceful "out of memory" alert rather than letting the projector crash... We then test for gMac which is a global variable we set to TRUE if we are running on a Mac. If it's not a Mac we then issue the magical puppetSound( mySoundChannel, 0 ) mySoundChannel is the property variable which holds the number of the sound channel for this particular SoundChannel object. If we are running in gTestMode (a global used during debugging) we output that a requested sound is missing. In the final project gTestMode is set to false. Hope this info helps... -MikeS PS Some of the parenthesis are not necessary but I use them to make the code easier to read...
Date: Dec. 18, 1996 What I've found so far is that there are at least two distinct problems with sound under Windows that are not a problem on the Mac. #1) PuppetSound: There is a bug in Director's implementation of puppetSound on ALL Windows machines (NOT MAC) that sounds will be forever locked in memory unless a puppetSound channel, 0 is used to clear the channel before playing any new sounds. This manifests itself as a memory leak that may ultimately cause a GPF crash. Already used sound cast members will not be cleared from memory, even if issuing an "unloadCast" command. I wrote the DreamLight RAMLight while tracking down this bug. I verified this bug on D4.04 for Windows and D5 for Windows. I also verified that it does not exist in D4.04 for Mac. I don't think this is documented, or if it is, I couldn't find it... I have posted the full 1,2,3 steps to reproduce this bug on the list in the past...and will happily forward them to anyone else that is interested... :-) PuppetSound work around:
if the machineType = 256 then puppetSound whichChannel, 0 puppetSound whichChannel, whichSound where whichChannel and whichSound are replaced with the proper channel and sound references... by clearing the channel BEFORE playing a new sound you don't have to worry about tracking each sound as it plays and clearing it when it's done. Although be aware that this means the last sound played is still hanging around in RAM until a new sound is played...even if you use "unloadCast" If you need to clear that one out you'll need to wait for it to finish and puppetSound whichChannel,0 before using unloadCast. This leads to the next windows problem... #2) SoundBusy: There is a conflict with some older soundblaster drivers particularly on Compaq Proliena and Ast Bravo's that interferre with soundBusy returning proper values. This manifests itself as soundBusy repeat loops becoming infinite only in certain instances on certain PC's and not on others or on the Mac. It also is not gauranteed to fail. In our case it was only happening upon jumping from movie to movie. If I played each movie individually soundBusy worked ok. I verified this problem on D4.04 for Windows but I have not tested this in D5 for Windows. I have verified that the problem does not exist in D4.04 on the Mac. I don't think this is documented, again, if it is I couldn't find it. SoundBusy work around: Uncomment this line: MixSericeMode=0 in each of the sound override sections of the projector.ini file. This forces the mixer to use a timer that seems to alleviate the problem on these machines. This may need additional testing to ensure that it doesn't "break" or hinder performance on other Windows machines... Anyone else want to test this on their PC's to see if it causes any unexpected trouble? ;-) You should also allow a delay before using soundBusy to see if a sound has begun to play. This is documented to give enough time for the soundBusy to register that a sound has indeed begun to play even on a Mac. This is correct operation and not a bug. If you test soundBusy too soon, the results will be returned BEFORE the sound starts playing, so it won't yet register TRUE. We typically issue an updateStage to start the sound playing before using any soundBusy. It has been suggested that this may also contribute to item #2 above and that delaying using soundBusy before entering such a wait loop may help. I have tested delaying soundBusy up to a full second (60 ticks) before entering the loop. In our particular situation, it did not help. The only way I was able to get reliable results using soundBusy with the old soundBlaster driver found on the Compaq Prolinea was to use the MixServiceMode=0 setting in the .ini file. -MikeS
Date: Dec. 2, 1997 >Best course, from all I've seen and heard, is to advise consumers >that if their >audio and video drivers correctly perform all standard Windows audio/video >functions, that they'll work just fine for your multimedia. I wish this were true, but that is not what I found in this case. The older driver does work correctly for standard Windows 3.1 functions but does not work correctly with Director's SoundBusy under the default settings of the .ini file. That is why we were in a bind...
>On that SB system, >the 4.0 drivers and above should work normally. I agree that ideally the customers should upgrade their sound drivers... Unfortunately, telling all Compaq Prolinea and AST Bravo users to upgrade their sound drivers was not a solution our publisher agreed with. (It would have been much easier for us. ;-) It seems many of the old drivers are still circulating. We just rented a Compaq Prolinea and it was outfitted as I described before, with an older driver... It turned out that by editing the projector.ini file we were able to get proper feedback from soundBusy. We included the following in each of the override sections... MixSericeMode=0 Any others out there that can't force their customers to upgrade their sound drivers can try this as well...be sure to test this on as many machines as possible though. -MikeS
Date: Nov. 26, 1996
>When we jump from one movie to another, the movie we jump to hangs anytime >we are waiting for soundBusy to become false. No crash, but when the sound >finishes, soundBusy does not become false so the program continues to execute >the wait loop... Well, after posting this question I began some investigations and did a search on back digests of the list. This issue has popped up a few times... Some suggestions linked it to ExitLock, External sounds, repeats rather than frame loops and older SoundBlaster drivers. Well we are using ExitLock (and we need to) so I didn't look at that too much. We are using PuppetSounds so External sounds aren't the problem. It hangs in both repeat AND frame loops, so that's not the problem. One machine that fails is as follows:
It runs fine on our Digital Starion 486 PC with Windows 3.11 and a built in sound card. There was also an entry in the digests that mentioned editing the projector.ini file to fix the problem. A number of items were suggested to change so I tried them all... IT WORKED! Then one by one I removed each changed line to pinpoint exactly what line was fixing the problem. It turned out the only line that needed to be changed was one in the Low Mono Overide (since we are already forcing only mono elsewhere in the ini file)
[Low Mono Override] MixSericeMode=0 This is marked as the default value anyway but if it's not explicitly uncommented in the ini file, our soundBusy commands fail. The soundBusy seems to fail only when jumping from movie to movie so I'm sure there is more involved that is the root cause of this in Windows. Perhaps it's related to the use of the ExitLock, multiple movies, multiple sounds, old drivers and the soundBusy. Maybe the ExitLock and sound mixing are causing internal timing problems that forcing the MixServiceMode to 0 fixes by forcing the sound driver to use a timer. I'm only guessing here... Well anyway this seems to solve the problem so far. John D. I don't have a 1-2-3 steps to reproduce this as you had asked in the digest but maybe some of this information can point you guys in the right direction? We have already sent a pre-release beta of this project we are working on called KeyQuest to the Director team. Maybe you guys can try to run it on a Compaq Prolinea to see if it hangs. Then by adjusting the .ini file as outlined above see if it "unsticks" itself. BTW this is all in Director 4.04 since we were already in Alpha when Director 5 shipped... -MikeS PS. Now I need to figure out what's slowing down our dummy DOS section...
Date: Nov. 26, 1996 OK, guys and gals, Now I have a question for you all... ;-) As I embark on a mission to seek and destroy a nasty Windows bug, I thought I'd toss it out there first to see if anyone else has run into this problem before. We have a CDROM currently in Beta. The Mac version runs fine (not surprisingly ;-). The Windows version runs fine on MOST PC's. However on a few select PC's such as a Compaq Prolinea with Windows 3.1 we are encountering some bizarre behavior. We were getting reports from the publisher about hangs on a few machines. It ran fine on the Mac and our PC test machines so we had to go out and rent a Compaq Prolinea to also test it on. Lo and Behold, on the Compaq Prolinea it hangs... When we jump from one movie to another, the movie we jump to will hang anytime we are waiting for soundBusy to become false. No crash, but when the sound finishes, soundBusy does not become false so the program continues to execute the wait loop... It does this in each of the following cases...
repeat while soundBusy( mySoundChannel ) end repeat or
in an exitframe handler if soundBusy( whichSoundChannel ) then go to the frame (The code above is not the real code, it's just to explain the types of instances where this is happening off the top of my head.) If I run the movie by itself everything is fine it's only from jumping from movie to movie. Again everything runs fine on the Mac and most PC's... I figured I'd toss this out there first to see if anyone has already seen this behavior... Now I'll start ripping apart the movies to isolate why it fails by jumping from movie to movie only on select Windows machines... Also, on the Compaq Prolinea a section of the movie that simulates an old DOS type machine by displaying lines of text on the screen runs extremely slowly. Again, it's fine on the Mac and most other PC's. I'll have to look into that one after I isolate the soundBusy bug... -MikeS
Date: Nov. 1, 1996
>> ... be careful about possible memory/performance impact on >>Windows since Director is doing the sound mixing rather than the OS like on >>the Mac. > >This was a concern for Director 4 because the baseline machine 2 years ago >was something like a 386/25. Now that the entry-level machine is something >like a Pentium 75, you will find that 8 channels of sound has a measurable >but small impact on performance. Quite true, but our current hybrid CDROM in beta stages now (in D4) is hitting some Macromix.DLL crashes on low end (4MB free ram 486 windows 3.11 which is still considered the bottom target machine by our publisher) windows machines when everything works perfectly on the Mac. It may be a problem with sound cards or any number of things under windows, but my word of caution still stands. The more tricks we play with audio under windows, the more GPF crashes we hit in Macromix.DLL when none of this stuff crashes on the Mac (4MB free ram 68030)... That's what I meant about performance, crashes, not just speed issues. The sound handling on the windows machines is just not as robust. It may not really have anything to do with Director (I wasn't implying that it was Director's problem, just windows), but it's much more finicky than the Mac...there is also the puppetSound not releasing cast members from RAM issue, under windows, that I reported and was cautioning about. So I'm not saying not to use extra sound channels under windows, just keep your eyes open and test everything... a lot... We finally had to turn off our background ambiant sounds on the windows version of our hybrid project. We recently sent beta3 copies of this project (KeyQuest) to Bud, Rix, and a few others over at Macromedia as promotional samples. Borrow a copy from them if you'd like to run it through the gauntlet under windows to see what you come up with. Then run it on the Mac to see what the windows users are missing... ;-) 90% of all crashes and headaches we encountered on this hybrid CDROM project came from the windows side...and many of them had nothing to do with Director itself. Take it from one who's been in the trenches... deep in the trenches... with mud all over my face... ;-) Tread warily on the wild windows side of the tracks... ;-{ Romp freely on the peaceful Mac side of the tracks... :-) -MikeS
Date: Sep. 26, 1996
>>but in some parts we >>need to have more than 3 sounds playing. Simply edit your Director.ini file. On Windows you must edit the projectorName.ini file (copied from the Director.ini) where projectorName is the actual name of your projector. The Default number of channels is 4 but can be raised higher. I forget which line to edit but it was pretty clearly commented in the Director.ini file. It's called something like MacroMixMax or some such variable... If you increase this be careful about possible memory/performance impact on Windows since Director is doing the sound mixing rather than the OS like on the Mac.
Sep. 16, 1996
>re 'screeching/distorted' sounds >in DFW4.04. We're still struggling to find the cause of this. I'm not sure if your problem is the same as one we ran into, but we had a case of a "screeching" sound on our DFW 4.0.4 version of a CDROM (Mac versoin was fine). We traced it to a specific sound being mixed with another sound through the MACROMIX.DLL. We were mixing background sounds in one chanel with a voiceover in another chanel. I'm not sure exactly what caused it, but creating a brand new version of the voiceover sound fixed the problem in our case. (though we are still having some crashes reported in MACROMIX on some low end PC's...) -MikeS
Date: Jul. 22, 1996
>You might try using the puppetSound option instead of the channels. It's >easier (in my experience) to control sound in this manner. You can create >a 1/3 second 'silence' sound to clear the puppetSound buffer at any stage >and that will give you your instant silence. Be careful using the puppetSound in DfW movies. If you use it in DfW you must use puppetSound x, FALSE when the sound is done. If you just puppetSound another sound after the first (even if it's the "silent" sound mentioned above) then the first sound will be locked in RAM and DfW will not unload it when issuing an unload cast etc. DfM will allow the unloadCast command to unload any sounds that had been played, as long as they are not currently playing but not DfW. This was a DfW bug that we ran into that caused our Windows version of a current hybrid CDROM to crash after a while since the puppetSounds were soaking up all the RAM and not allowing them to be released. We wrote the DreamLight RAMLight utility during our efforts to isolate this particular DfW bug... Here is a repost of the DfW [SDF] report incase you missed it:
--- >First do this in Director 4.0.4 on the Mac. > >1) Create a sound cast member, let's put it in cast slot 1. >2) In the message window type: puppetSound 1, 1 >3) once the sound finishes type: unloadCast >4) then type: put the loaded of cast 1 >5) You will be told that the sound is unloaded (as expected). > >Now go to either Dir 4.0.4 on Windows or 5.0 on Windows (I didn't try 5.0 Mac) >Follow the same five steps and you will be told that the sound is still loaded. > >I just wasted quite some time tracing what appeared to be a memory leak to >this. In our windows version of a project, none of the sound cast members >were being released. Eventually this crashes the program when it runs out >of memory. > >On the windows version you must first issue a puppetSound 1, 0 after >playing each sound otherwise it will be locked in memory forever even if >you subsequently... > >puppetSound 1, 2 > >(where 2 is another sound cast member) > >The first one is still locked up in memory unless you had done a >puppetsound 1,0 as soon as it was done playing and cleared it from memory. > >This is a pain since we then must have a handler wait around to track when >each sound finishes and dispose of it. If it could work like on the Mac >where once it is done playing and you had moved onto another sound all the >earlier sounds are cleared when issuing an unloadCast command, I'd be much >happier. > >The workaround is to issue a puppetSound 1,0 before playing the next sound. > >on playMySound whichSound, whichChannel > global gMac > if NOT gMac then puppetSound whichChannel, 0 > puppetSound whichChannel, whichSound >end -MikeS
Date: Jan. 8, 1996
>I am at a loss. I cannot seem to find any explanation for why sounds in >channel one will only play once. If you replay the frames a second time the >sound in channel one will not play. I am sure that somewhere there is an >explanation but I have be unable to find it in the manuals etc. Is there a >lingo command that I can use to turn the sound back on? Thanks--Coryndon I'm not sure exactly what you are trying to do but here are a couple of items to check. Don't let a looping sound run in a "go to the frame" loop if it's the very last frame of a movie. This kills the sound for some reason when the playback head jumps. It's a bug in Director. Simply add anything else after that frame, it never needs to be used but just there so the loop isn't the last frame. I just duplicate the last frame and then delete the duplicated loop script. This frame is never seen but it keeps the sound from dying. (I have verified as of 8/5/97 that this bug still exists in Director 6!) Also, check to see that you don't have a sound fadeOut 1 command in there that is turning off that sound chanel. If you do, you can add a sound fadeIn command to turn it back on. If you fade out a sound and then try to start a new sound before the fade out is complete, your new sound may not play... Also, make sure your loops are set correctly in the sound files themselves if they are looping sounds. Otherwise once they play once, they won't repeat unless retriggered. You can retrigger them by leaving a blank spot in the Sound 1 channel at specific points rather than having it completely filled with the same sound which would require a working looped sound. Also, if it's looped be sure that loop is checked in the sound's cast info dialog. That's about all that comes to the top of my head to check... Hope something here clicks. -MikeS
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
To view this site properly, please upgrade to a browser that supports current Web standards.
|
 |
 |
 |
 |
 |