** Dev Blog September 18th 2014 **
Developing works in cycles: You have an idea, you work out a way to implement that, you implement it, you run into trouble, you fix it, and somewhere on the way there comes the next idea starting another cycle...
People have been asking me: "When will you be done with what you are working on?", and with the experience of three years on the job, I was quite right about the time frame for the last update - even my estimated three weeks of post-update bugfixes turned out to be pretty accurate.
Since I am using several plugged in libraries that were written by external coders (see the -> credits page), bugchecking does always involve keeping those plug-ins up to date, and sometimes this leads to unexpected trouble. In the most recent case, the updated player plugin didnt work with the updated mobile Chrome app, so before taking some well needed days off, I have been involved in investigating a workaround for this.
I kind of like the "swarm intelligence" thing that happens in such cases, because a lot of coders who use the same plugin will start to look for a solution, so its mostly just a matter of days until someone comes up with something. I do enjoy being part of this a lot, and in this particular case it took about ten days until a workaround was found.
The usage of such plug-ins has its Pros & Cons - some ad viable functionality, but the more external code is used, the bigger the amount of work needed to make sure the current combination of plug-ins works together well - and since there is not necessaryly any information coming my way whenever a plug in or a browser gets updated, it is sometimes a bit difficult to maintain.
Currently, the pool of external code includes the functionalities mobile detection, usage statistics, audio player, upload handler, smooth JS reloading and ad delivery plus the external code to provide the Facebook log in option.
Getting this to work in the 8 major browsers on apple, android and windows machines does take some shephearding at times, while my focus rests with the unique code developed for wkiloops.
One of the definete pro arguments for using plugins is the fact that there are several plugins offering the same or similar functionalities which compete with each other - so every now and then it is worth having another look around the scene to see if some new plugin might be more advanced or better suiting for ones needs.
So, while waiting for the player plugin to get fixed, I had a little look around on alternatives and spotted wavesurfer.js - a CreativeCommons licensed piece of code that doesnt only provide the expected audio player functionalities but also has some additional features which really struck me as interesting for our use case here.
After looking into it a little more, I also noticed some issues that the wavesufer developers have not solved in a way that would work well on wikiloops so far - it is a great piece of code, but like wikiloops, it is in development and has some things still on the roadmap, so no offence at all.
I ended up trying to tweak the supplied code in a way that would suit my intention (thank you, open source!), and by designing a unique mix of some of wavesurfers features and the good old jplayer plugin, the new wikiloops player is coming into shape - starting off a new development cycle just as I was finishing the last one :)
I'm in good faith this one will not take five months until it may be used on the live interface.
The new player will feature a display of the waveform and the ability to loop segments within a track (p.e. to practise a second part or a tricky break only). To offer a little visual aid on the tracks structure, changes and parts may be marked with couloured markers, so it may become a bit easier to "see it coming" when jamming along.
Thanks to the wavesurfer plugin, the generation of the waveforms will not cause the expected extra server load (which was always the big con argument up until this point). While the original plugin relies on analyzing the mp3 after it has finished downloading in a browser and dumps the displayed waveform as soon as a page is closed, I figured it was much more convenient to only create a waveform once for each file, so there would be no waiting for the download to finish.
This seems to work well at this point, and as I type, there is an automated script running in a second browser window which is calling up every single one of the 20.000+ tracks in my local backup folder, creating and saving a waveform for each. Looks like this task is going to take about two days on my laptop :)
What else is on the roadmap?
To drop a few more techie terms, I am aiming to implement https and investigating use of CDNs, there are the volonteers willing to work on further translations who I have to assist and enable, and last but not least some simply forgotten functionalities left over from the last update. It wont get boring anytime soon it seems.
ending with the traditional stats of today:
members: 16.587
tracks up: 20.731
Developing works in cycles: You have an idea, you work out a way to implement that, you implement it, you run into trouble, you fix it, and somewhere on the way there comes the next idea starting another cycle...
People have been asking me: "When will you be done with what you are working on?", and with the experience of three years on the job, I was quite right about the time frame for the last update - even my estimated three weeks of post-update bugfixes turned out to be pretty accurate.
Since I am using several plugged in libraries that were written by external coders (see the -> credits page), bugchecking does always involve keeping those plug-ins up to date, and sometimes this leads to unexpected trouble. In the most recent case, the updated player plugin didnt work with the updated mobile Chrome app, so before taking some well needed days off, I have been involved in investigating a workaround for this.
I kind of like the "swarm intelligence" thing that happens in such cases, because a lot of coders who use the same plugin will start to look for a solution, so its mostly just a matter of days until someone comes up with something. I do enjoy being part of this a lot, and in this particular case it took about ten days until a workaround was found.
The usage of such plug-ins has its Pros & Cons - some ad viable functionality, but the more external code is used, the bigger the amount of work needed to make sure the current combination of plug-ins works together well - and since there is not necessaryly any information coming my way whenever a plug in or a browser gets updated, it is sometimes a bit difficult to maintain.
Currently, the pool of external code includes the functionalities mobile detection, usage statistics, audio player, upload handler, smooth JS reloading and ad delivery plus the external code to provide the Facebook log in option.
Getting this to work in the 8 major browsers on apple, android and windows machines does take some shephearding at times, while my focus rests with the unique code developed for wkiloops.
One of the definete pro arguments for using plugins is the fact that there are several plugins offering the same or similar functionalities which compete with each other - so every now and then it is worth having another look around the scene to see if some new plugin might be more advanced or better suiting for ones needs.
So, while waiting for the player plugin to get fixed, I had a little look around on alternatives and spotted wavesurfer.js - a CreativeCommons licensed piece of code that doesnt only provide the expected audio player functionalities but also has some additional features which really struck me as interesting for our use case here.
After looking into it a little more, I also noticed some issues that the wavesufer developers have not solved in a way that would work well on wikiloops so far - it is a great piece of code, but like wikiloops, it is in development and has some things still on the roadmap, so no offence at all.
I ended up trying to tweak the supplied code in a way that would suit my intention (thank you, open source!), and by designing a unique mix of some of wavesurfers features and the good old jplayer plugin, the new wikiloops player is coming into shape - starting off a new development cycle just as I was finishing the last one :)
I'm in good faith this one will not take five months until it may be used on the live interface.
The new player will feature a display of the waveform and the ability to loop segments within a track (p.e. to practise a second part or a tricky break only). To offer a little visual aid on the tracks structure, changes and parts may be marked with couloured markers, so it may become a bit easier to "see it coming" when jamming along.
Thanks to the wavesurfer plugin, the generation of the waveforms will not cause the expected extra server load (which was always the big con argument up until this point). While the original plugin relies on analyzing the mp3 after it has finished downloading in a browser and dumps the displayed waveform as soon as a page is closed, I figured it was much more convenient to only create a waveform once for each file, so there would be no waiting for the download to finish.
This seems to work well at this point, and as I type, there is an automated script running in a second browser window which is calling up every single one of the 20.000+ tracks in my local backup folder, creating and saving a waveform for each. Looks like this task is going to take about two days on my laptop :)
What else is on the roadmap?
To drop a few more techie terms, I am aiming to implement https and investigating use of CDNs, there are the volonteers willing to work on further translations who I have to assist and enable, and last but not least some simply forgotten functionalities left over from the last update. It wont get boring anytime soon it seems.
ending with the traditional stats of today:
members: 16.587
tracks up: 20.731
No Comments have been posted.
wikiloops online jamsessions are brought to you with friendly
support by:
What's really unique here is the positive attitude of the community, with encouragement and support for everyone. I found that nowhere else on the net.
Lutz