Suggestion: Play Sample, Complex

[Nifflas]

I've always thought that it may not be the best solution to add a new action for every possible way to play a sample (repeat, on specific channel, internal or external file).

If e.g. the "play internal sample (pick sample with expression)" feature is added, imagine how many new actions we'll get to cover all the possible combinations:

- Play sample
- Play sample on channel
- Play and loop sample
- Play and loop sample on channel
- Play sample file
- Play sample file on channel
- Play and loop sample file
- Play and loop sample file on channel
- Play sample (pick sample with expression)
- Play sample (pick sample with expression) on channel
- Play and loop sample (pick sample with expression)
- Play and loop sample (pick sample with expression) on channel

I'd like to propose something different. I understand that it's extremely unlikely that this will make it into MMF2, but it could be a great MMF3 feature. I'd like all "play sample" actions to be reduced down to two actions only.

* Play Sample (simple), which plays an internal sample on any channel

* Play Sample (complex), which opens a series of expression input boxes:
- Embedded or external (0 for embedded, 1 for external)
- Which sample (internal sample name or external file name)
- Channel (-1 for "any", 0 to 31 for a specific channel)
- Volume (-1 for channel setting, 0 to 100 for a specific volume)
- Pan (-1 for channel setting, 0 to 100 for a specific pan)
- Frequency (-1 for channel setting, 0 for sample default, 1 or higher for a specific frequency)
- Repeat count (-1 for infinite loop, 0 for 'play once' and 1 or higher for repeat)

This would prevent an additional problem with MMF - currently if you play an internal sample, and then change the sample volume of it, a small fraction of the sample can play before the "change sample volume" event have had a chance to run, resulting in a digital 'click'. A way to solve this have been to change the volume on a channel, then to start playing a sample on that specific channel. Unfortunately, this also requires the user to set up his own manual voice allocation, since (s)he can't rely on the automatic one any longer. My proposal would solve this too.

In a similar way, I'd like the "change channel volume, change pan, change position, change frequency, etc." actions to be reduced down to two simple "Modify channel" and "Modify sample" actions that lets you set all the parameters at once and -1 for "no change".

I guess the problem with my solution is possible lack of backwards compatibility, but the way the actions are set up now are far from optimal from a technical and functional aspect, they make new sound related features very hard to add without making that action list grow even more.

[Dynamite]

- Repeat count (-1 for infinite loop, 0 for 'play once' and 1 or higher for repeat)

If you type in "0" it already gives you an infinite loop. No need to add that

[Dynasoft]

And "1" is of course play once already.

[Nifflas]

Ah, you're right. Since the action was called "Repeat", I was under the impression that the number determined the numbers of actual repeats (e.g. that 1 would play the sound and then repeat it 1 time). I've never used anything other than infinite loops, so I've never used another value than 0.

However, to be consistent (because in all my expression examples, negative values are used to point out an alternative behaviour, except with the frequency thing where I should have recommended -2 for channel setting and -1 for sample default), I'd still like -1 to mean "infinite", while 0 and above determines the number of times to play the sound. Thus, a value of 0 would result in the sound not being played at all.

No comments about the rest? Do the others of you prefer each different way to play a sample to be it's own action?

[mobichan]

I found the sound player to only be handy for one time "fire and forget" sound effects, since I needed music to change based on events in my game and the sound handling didn't cache anything so I got alot of momentary pops of silence. I ended up using Onu for the music in the end.

The workflow I found necessary involved organizing the channels so there were no "overlaps" so that I could play with individual sound volumes and stop playback when necessary. This need to meticulously organize seemed like the bigger headache than the fact that I needed to use alot of actions.

But to answer your question, I don't think my own personal workflow would benefit greatly from reducing the number of actions in my code. I might not know what sort of savings would be gained from 30 less sound related actions in my code, but it doesn't seem like it would be very much. But maybe a music game would benefit from your idea.

It would be nice if there were more options overall to the default sound controls, though. Not sure if that helped, but it's my 2 cents.

Mobichan

[Pkeod]

Nifflas, I feel your pain. Additional work on this will have to be done by a third party extension developer. I did ask Yves about more specific features, because of the problems the current limitations present, but it seems 1. a lot of other development has greater precedence 2. the current system is working as intended.

[Nifflas]

But to answer your question, I don't think my own personal workflow would benefit greatly from reducing the number of actions in my code.

To me, it's not really about changing my workflow. It's just about changing the actions to work in a more logical and optimal way that doesn't contain the errors that currently exists (e.g. that you need manual channel allocation just to play a sample with a specific volume while staying sure that a digital "pop" sound isn't heard an any machine).