I am Keith. I have played guitar in CAPDOWN for many years. I have also been running my mobile recording service for many years too and have helped a number of artists achieve top quality recordings at very fair rates.
I will give you a quote if required, please use the CONTACT section to get in touch...
I am based in Milton Keynes yet run a mobile rig - I usually use an artist's practice space to capture a recording.
Editing and mixing will be done at my own premises, and then I'll host the files on a user's page here so you can log in to listen and we can discuss any changes you require. All multitrack stem files will be provided back to you and I can also provide a 'mastered' version of the recordings. The final mix will also be supplied to you 'un-mastered' as 24bit stereo files for mastering elsewhere if required.
I will not however, burn anything to disc from now on... Test mix CD's invariably end up in landfill sites as the medium is non-recyclable.
My website does not store or share user's personal data. #ownyourdata.
Built with Sublime Text 3.2.1, Transmit 5.5.2 and using operating systems by
release notes for build_0519
.modal-body css now has red links (this was for release notes)
Removed smoothscroll.js from all pages - too many errors and pointless...
Clean up the foreach clone >= $version code in functions.php- WRAP IN FUNCTION if possible
^ The first 2 versions of this (save new deployed/not deployed) loop do not have the <= $version clause
?? Think this is expected as you are inserting new version which must be the max version. As $version does not exist in this scenario, the <= clause cannot be used...
?? Can't seem to wrap array build into function... none of the > versions from rc end up in prod when creating new clone of deployed bersion in rc.
Introduce notification labels to state whether the last action was pushed to clone DB?
CMS version 536 has been updated but is not deployed (keep grey and keep message as is)
It was also pushed to the PRODUCION database (maybe green)
If we want to start listening to whether switches are changed, we'll need to start giving these inputs unique IDs. Currently they are all set to true/false and I am not sure this needs to be this way? Their value should be true/false as they are currently, but surely their IDs can be unique...? They could have the same ID as their name I think - test this and potentially make this change to all switches prior to investigating event listeners and subsequent jQuery functionality.
Further to this, after next deploy investigate having two j-confirm models - 1 modal and 3 modal versions. JS vars can deal with the content on a case basis.