The Drax Files 5: Engrama make SL rock

The fifth segment of The Drax Files moves somewhat away from the central theme of the series to date, that of content creators and their work in Second Life and shines a light on the live music scene within SL. In doing so, it again demonstrates the rich diversity of opportunity which is available within the digital world.

Engrama: image courtesy of Draxtor Despres
Engrama (image courtesy of Draxtor Despres)

Engrama is a partnership of musicians in both in the real world and in SL in the form of Argentine-born Pupito Helstein and his Spanish girlfriend Lakua Arriaga. Like many musicians who have embraced Second Life, they’ve found that the platform has provided them with a unique world-wide reach that provides an added dimension to their real-world lives.

“We have no backing tracks, it’s all live,” Pipito says of their in-world performances, “We prefer to play original songs; In fact we improvise in Second Life, we sometimes create even original songs.”

“It totally depends on the mood of the crowd,” Lakua adds.

Engrama: Lakua (image courtesy of Draxtor Despres)
Engrama: Lakua (image courtesy of Draxtor Despres)

Operating from their mountain village home, Engrama have developed not only a distinctive voice, focusing on post-rock era music (which includes covers of Sigur Ros, Radiohead and others as well as their own original pieces), but also a distinctive presence. They’ve taken to building their own stage sets and instruments to better reflect their music and style. More recently, this has led the couple into wider fields of content creation, making prefab homes, furniture and clothing. Pupito has even attempted to encourage his musician friends to embrace Second life, spending time creating unique avatars for them.

Engrama: Pupito (image courtesy of Draxtor Despres)
Engrama: Pupito (image courtesy of Draxtor Despres)

“There is one magic thing in Second Life,” Lakua says as the couple distinguish between their real world and Second Life experiences, “[That’s] when people send us messages like, ‘Hey guys, I heard Engrama music at the Colorado [Grand] Canyon on a trip!'”

“People record our Second Life shows,” Pupito adds, “And then they listen to them on their iPods.”

“They share with us how our music makes them feel,” Lakua finishes.

This is not boasting in any way; the statements are made in a tone of delight and wonder which demonstrates both Lakua and Pupito are themselves awed by the impact their music can have on an audience they might otherwise never reach. “This  is real interaction,” Lakua states as the video closes, “Second Life is a parallel life, they [it and real life] can go together, and sometimes they can cross.”

And that is again the magical power contained within Second Life – not only that we can come into the digital world and free ourselves from the constraints of everyday life and business and create and play and have a lot of fun or share time with others – but that we have within this digital domain the ability to reach far beyond ourselves, to touch others and be touched by them, to share, uplift and help others, and be a part of lives, and make them a part of our own in ways which simply cannot be achieved in the physical world.

Continue reading “The Drax Files 5: Engrama make SL rock”

SL projects update 18 (3): more on the viewer

Viewer Release Process

Following-on from the announcement of a new process for viewer releases Oz Linden provided more information on the process as it will operate going forward during the Open-Dev meeting on Wednesday May 2nd, and gave a clarification on my original post after I’d mistakenly referred to individual viewer “release candidate channels”, rather than more correctly, “release candidates”. His comment in full reads:

Oz Linden
Oz Linden

The release candidates will be updates in the regular release channel, not separate candidate channels. The candidates will be in a named “cohort” within the channel, but the cohort name is not built into the viewer the way a channel name is, which means we will be able to move a candidate from its named cohort to the default without rebuilding it – the build we test will be exactly what we release. Candidates will be indistinguishable from the default release viewer (the one on the main download page) except for the version number and the new features.

The new process also means that officially, individual viewers will no longer be referred to by specific project channel names (such as CHUI, Materials Processing, etc.). Instead, they’ll be referred to by their full 4-part number (i.e. 3.5.1.274847 rather than the “Materials project viewer”).  This also means there is likely to be at least one update to the Bug Tracker so that the Environment box in the form will no longer allow a report to be submitted until viewer channel and version number have been recorded.

As a result of these changes, Oz indicated that the development viewer channel has already been depreciated, and that the beta channel, as mentioned in my original piece will be depreciated as the Lab switches over to the new system.  When a candidate viewer is ready for public consumption, it will appear on the  Alternate Viewers wiki page where it can be downloaded.

I’ll be making changes to my Viewer Round-up Page to match the new system as it comes into play.

Current SL Viewer Status Update

In the meantime, and in the lead-up to the new release process, there is expected to be a further beta viewer release (3.5.2 code), which will include the FMOD Ex updates in it, and for which Oz extended thanks to the Singularity team for their work.

The Mac Cocoa project is a little stalled. This is because, to quote Oz, “We’ve been stealing people [TPV devs] from Cocoa to get Materials done. The good news is that it’s working, we’re really knocking down bugs at a steady clip.”

The mesh deformer also remains stalled. This is again due to manpower issues but this time internal to LL. However, Oz again wanted to reassure people, stating of the deformer, “There are things I’ve given up on at this job, but that isn’t one of them.” Sadly, his plate is also full with the Materials project at the moment, together with things like the new viewer release process.

Related Links

Keisei: the returning

Back in September last year, I visited Keisei, Daddio Dow’s fabulous region, and was captivated. To my shame, I admit I’ve not had any real opportunity to get back since, despite the region being so evocative.

However, when a personal invitation arrives from Daddio, asking me whether I’d like to pay a visit and see what is new following some work he’s carried out, I was grabbing my camera and heading straight on over.

Keisei
Keisei

“I’ve done a bit of remodelling,” Daddio told me, “but what I think you and your readers will really get a kick out of is not so much the sim, but the trees I’ve found by Mitsuko Kytori of Hayabusa Designs. These trees and plants are marvels and deserve to be recognized, photographed and admired.” I have to admit that having seen them, I can only agree.

The changes made to the region are both subtle and widespread, and definitely make Keisei a place to visit once more. I’m just irritated that due to the “ERROR: LLDrawable::destroy: Illegal deletion of LLDrawable!” crash when using the snapshot floater, and which seems to be prevalent in SSB/A-enabled v3 viewers, I’m restricted grabbing screen caps a lot of the time on regions which are either busy or (as in this case) use a sim surround. This tends to make for a Growly Me.

Keisei
Keisei

Among the changes made are a number of new private residences – so please take care should you explore; the majority of the region is open to visitors, but some of the houses are equipped with security systems, and all visitors are asked to respect residents’ privacy.

Other changes within Keisei include a relocation for the bath house, which comes down from the sky while the tree house spa now sits up at 1,000m. The arrival point has been beautifully re-worked, and elements of the coastline remodelled; all of which adds up to a lot to see and enjoy.

Keisei
Keisei

The region remains a photographer’s delight, and I really do urge anyone into SL photography who has not visited Keisei to do so; there are so many opportunities here for some stunning images – and the entire region naturally lends itself to a host of windlight settings.

I have to confess that I’d actually missed the place as I nosed around and snapped away. This is a region which really is worth the time to visit. And if you’re looking for an oriental-themed home, there are a couple of parcels available for rent as I write!

Related Links

LL announce revamp to the viewer release process

secondlifeLinden Lab have announced a revamp to the way in which they will be releasing viewer updates in future.

Currently, the process for the majority of viewer changes is that they go through a progression – generally being seen first in the development channel (or sometimes prior to that in a project viewer), before moving through to the beat viewer (where updates go through what is effectively a final validation  / user test) prior to being adopted into the SL release viewer.

This system has generally worked, but can cause problems, particularly when there is a lot going on in terms of projects and updates, and things end up being “queued up” for the release (as is currently the case, where CHUI, Server-side Baking / Appearance, and a host of other updates / fixes are concerned all being “queued” awaiting their turn in the beta viewer release channel.

Another problem – as seen at the end of last year – can be that should a significant issue occur within the beta viewer code, it can completely block further viewer releases until such time as the problem can be tracked down and effectively fixed. Last year this meant that viewer updates were effectively stalled for around a two month period while LL sought to isolate and fix the problem.

To try to overcome any bottlenecks which might occur with viewer releases, the Lab is adopting a similar process to that used by the server-side code release mechanism, as the blog post explains:

We’ll release more than one new version at the same time in parallel to subsets of users for final validation, and then promote the most important of the best of those to the default Release Viewer when that testing shows it to be ready.

If a development project wants to put out an early version for testing prior to it being ready for the Release channel, a channel specific to that project (either ‘Project <project>’ for very early versions, or ‘Beta <project>’ for more mature ones) will be created, just like we do today. These will be shut down when the project is ready to move to final testing in the Release channel, and users in the early project test channels will automatically be upgraded to the corresponding Release candidate version.

This means that in the coming weeks, we’ll start to see different versions of the viewer start to appear in parallel in their own “release candidate” channels, and people will be able to choose which versions they want to download and try-out. Once it is deemed the code from a specific “release candidate” viewer is ready for release, it will be integrated into the SL viewer and made available to the community through the established mechanism. As such, the beta viewer channel will be vanishing in the near future.

Quite how well different flavours of the viewer will run together on a single computer for those who want to try-out more than one upcoming release remains to be seen. Generally, different versions of the SL viewer tend to play nicely together. However, as was seen with the 3.4 and 3.5 code base changes problems can occur. In that particularly instance, running a development or beta viewer using the 3.5 code and then swapping back to the SL release viewer on the 3.4 code resulted in all the toolbar buttons vanishing from the latter.

The overall hope is that this change will mean that specific features and updates will reach the release version of the viewer at a greater pace than can be achieved with the current process, which in turn should not only smooth the path for new capabilities and features to reach users quicker (allowing for the inevitable bugs and hiccups such projects tend to encounter anyway), but perhaps also help in get fixes for significant issues and problems out to the mainstream viewer.

SL projects update week 18 (2): server releases

Deployments for Week 18

The week 18 deployments make for interesting reading.

SLS Main Channel

On Tuesday April 30th, the Main channel was rolled back to release 13.04.05.273580, as a result of a widespread performance issue.

Release Candidate Channels

  • BlueSteel and LeTigre: both of these channels should remain on the Experience Keys project, but will also be reverting some changes, due to the same performance issue which is affecting the Main channel – release notes
  • Magnum: should remain on the same server maintenance project as week 17.  This project brings some new minor features to LSL, and fixes some crash modes.  This update fixes the grid performance issue, and fixes an issue in which llDialog() messages sent to the object owner could be incorrectly throttled – release notes.

The performance issue which caused the Main channel to see the re-deployment of an older release was described by Simon Linden as being related to problems with regions locating their neighbours. “The performance problem was really showing up between any one region trying to locate another on the grid … the system was actually working, but too close to the cliff for comfort.” The re-deployment means that the new LSL AO capabilities can no longer be compiled / run on any Main, BlueSteel or LeTigre regions, until the supporting code is rolled-out once more.

There is still no further detail on the Experience Keys project and whether this may / may not be more than a deployment of the Advanced Creation Tools permission system.

Interest List Update

Andrew Linden has been working on fixing a bug related to Meeroos (but which I’ve seen affecting other animals as well), which he describes as, “If you turn your camera away from a crowd of Meeroos, wait several seconds, then turn back around… the Meeroos will be updated, but not quite in the right order. So sometimes you’ll see a head move to the new position, then a fraction of a second later the rest of the body.  So I have a theoretical fix that doesn’t crash the simulator (anymore).” The fix in question has yet to be tested and QA’d, so there is no time frame for any release.

“Missing” Prims

While talking about the interest list work, Andrew answered a question on missing prims / linksets, again acknowledging it to be a viewer-side issue, before going on to say:

We think maybe it is fixed in a new viewer. But this new viewer I mention happens to be very crashy, so we haven’t opened up the source code for it yet nor have we submitted it to our QA team since they’ll just crash …  This is the viewer that goes with our new interest list changes which I mentioned a few weeks ago and people were wondering when the code would be put up on a public repo.

"Missing" prims - viewer-side fix possibly on the way?
“Missing” prims – viewer-side fix possibly on the way?

So a viewer-side fix, along with viewer-side interest list updates, looks to be somewhere on the horizon.

Region Crossings

There have been a number of reports of region crossings worsening again after seeing a significant improvement with the release of the fix for BUG-1814. A common issue has been avatars becoming “snagged” at a region boundary while the vehicle they were travelling in continuing on its way, sometimes being returned to their Lost and Found folder from a location two or three regions beyond where the avatar became stuck. Both prim/sculpt and mesh vehicles are affected when the problem occurs, and it is an issue which had been encountered prior to the widespread deployment of the BUG-1814 fix.

Getting "snagged" at a region crossing while my aircraft flew on was a problem I encountered several times over Blake Sea early in April. The problem has again manifested itself to many, and I've again encountered it while flying my mesh Spitfire Mark IX
Getting “snagged” at a region crossing while my aircraft flew on was a problem I encountered several times over Blake Sea early in April. The problem has again manifested itself to many, and I’ve again encountered it while flying my mesh Spitfire Mark IX

I’d actually encountered the problem on April 4th during a series of region crossing tests, but the problem no longer appeared to be occurring by the middle of the month.

The issue of region crossings was raised at the Simulator Meeting on Tuesday May 30th, but the discussion was dominated by the problems being encountered by one particular type of train. In commenting more generally on region crossings, Andrew Linden said, “I agree that region crossing on vehicles needs more work. I can’t promise that I’ll be working on that as soon as I’m done with this interest list project, but I’ll try to bring it up in the next ‘what do we work on next’ brainstorm that we have.”