Ban "Jukebox" items

I don't know if there is any such capability, but it is seems like there are fairly reasonable ways to control these items.


1. Allow people to create barriers preventing sound from coming in.

If we could build structures (or even phantom non-structures) that could prevent streams from preloading or playing at all, it would be fine.

2. The ability to mark portions of your land as 'internal audio only'. This so you can keep your house nice and quiet, without having to use prims for a 'silence' wall.

3. The ability to selective ban incoming streams from certain objects. I don't know how this would be implemented, but I imagine it would use some sort of dialogue similar to the push dialogue "You are receiving more than 10 preloads from this aural object. Would you like to continue receiving them?"


Bit

Okay, See, the problem isnt usually the sounds themselves, but the pre-loads that jukeboxes create. Ive seen a que list on my client in excess of 500 before. This is RIDICULOUS. Also, to Chris, 99.5% (fake statistic, however, more than likely true ) of the music in the jukeboxes are illegal to have on SL. The route-66 people had to change the A&W sign on their build.. why shouldnt THESE people have to delete their files?

I think most people are using the ZSound script (by BBC if I'm not mistaken.) It preloads the first 9.x second clip, then plays it, and at the same time preloads the following clip, and so on.

I use it in a few objects that play demoscene (i.e. non-RIAA-encumbered) tunes.

LSL does have a call that will trigger a sound that can only be heard within a defined cubic (well... six-sided anyway) volume. I forget why but for some reason it wasn't the best way to handle streaming music. I agree that we should be able to define volumes that variably dampen exterior noise (all the way to 100%.)

What he said. I'm not referring to sound in general, i'm just referring to these lovely jukebox items which love to just hammer preloads into you.

The music players which do their nice little prebuffer 1 play 1 are fine. It's good scripting practice, yay for them. However, note the thread title for the intended target of this message.

Perhaps a client side option to limit the number of incoming sounds, and sound distance limits? Much like particle count limits, avatar composite limits, draw distance, etc.

Mute audio working properly would solve my problem too though

Huns: As far as triggersound works, I don't think that it is constrained by a 6-sided volume? At least, no more than a regular playsound.

Triggersound is not compatable with sound queuing, but I don't think that's why most sound players don't use it, because they don't take advantage of sound queuing.

Preloading a single clip doesn't seem to be particularly effective, at least not the first time through. By the time the clip's loaded, it's too late. Preloading the entire song at the beginning may be more effective at getting all the sound to the client before it's actually needed.

[shrug] I've been working on my own music player which works somewhere between these two extremes, by preloading N clips. Maybe someone can find an agreeable constant for it. (attached file)

A.229. llTriggerSoundLimited

llTriggerSoundLimited(string sound, float volume, vector tne, vector bsw);


Plays a transient sound NOT attached to an object with its audible range limited by the axis aligned bounding box define by tne (top-north-eash) and bsw (bottom-south-west). The sound plays from a stationary position located at the center of the object at the time of the trigger. There is no limit to the number of triggered sounds which can be generated by an object, and calling llTriggerSound does not affect the attached sounds created by llPlaySound and llLoopSound. This is very useful for things like collision noises, explosions, etc. There is no way to stop or alter the volume of a sound triggered by this function.

It's also somewhat broken. As soon as you sit down, you won't hear any more sounds played with llTriggerSoundLimited. No matter if you're in- or outside of the defined box, or even sitting on the playing object itself.

Why a ban??

Is there no way to incorporate some scripting that will fix the intrusive nature of these creations??

I am not a scripter so I ask in all sincerity.

The most logical solution as I see it would be:
1) find a scripting fix to the sound intrusion

2) request that all 'jukebox' scripters use/use and improve this fix

3) stop supporting the scripters/builders
who do NOT use the fix.

Its a marketing solution.

The big 'boxes' that I've seen are/were created as sellable items.

Educate the consumer. Let the manufacturer know what you want. Use your buying/support power to implement those changes.

Knowing one such 'juke' builder personally...I can assure you that he would have no issue with adding a 'script fix' to his machines to make everyone happier with them.

Have you talked to any scripters or 'juke' builders about this si??

There are places in SL I cannot imagine without the jukebox type addition. There are people who truly love these items.

I do hear and understand the issues with them that you are having....

but is a BAN truly the first and best answer???

Just wondering...

~Alana

There is currently no way to fix it with scripts, as we have discussed above.

Anyone who knows me very well in SL knows I am not a big fan of jukeboxes, as I live next door to a club. I don't think they should be banned outright however but I am surprised that LL allows this in the first place. It has to be contributing to lag and taking up an enormous amount of server resources for such little benefit - it rarely plays smoothly anyway, and is such an annoyance to anyone in the vicinity who might not want to listen to Tupac right at that moment but still not mute their computer.

LL could easily solve this by putting a maximum limit on the number of sound clips you can put into an object. That would certainly solve this problem, though yes I realize it would kill music in SL. In suggestions, I have frequently suggested putting in support for streaming music natively, as opposed to this horrible hack that does nothing but lag and frustrate, not to mention is a huge copyright violation across the board.

Although they have had their share of problems with apparently not knowing how to fix any bugs whatsoever, There incorporated streaming music very elegantly and I would like to see a similar option in SL. I doubt that we will ever see full on-demand streaming of audio, as that would require a ridiculous amount of resources and would open up SL to copyright issues, but the solution that There used of basically functioning as a player for Shoutcast audio streams was very effective. Yes I know some people don't like Shoutcast and have a million other suggestions, but the concept is the same.

The bottom line is we need real streaming music support, and then the jukeboxes will go away. Jukebox makers are trying to fulfill an obvious demand for a variety of music in the game, since SL has not provided any other options, and I can't fault them for that.

I believe that the problem lies in all scripted songs (to make the total song) should be reduced, but not something like a 1 file (10 sec) song looped over and over. SL primary intention for wav files was to be used as sound effects and you avarager loop song here and there. Sounds are a huge load on bandwidth, and I feel that LL should not ban jukeboxes totally, but just give the option to not have to download them in the first place.



I feel this is the best solution to solve all Song Scripted object, and is a good idea. My juke box has about 5 songs on it and they are only 10 secs each (loops). Plus the way I am scripting my new script it has the ability to give the credit in the format of the file, to the author that created the song loop. And I am now adding a feature so it takes away the PreLoader on view of the object and only implement it when you play a new song.



Even though I feel this would help in such a case, you have to realise that stream their music data from a internet radio station would be as much of a strain on our bandwidths as the scirpted songs would.