En el caso que te gusta el bingo.
Here’s an idea to inject a bit of what’s missing from the recent tracks that I made in the 80s and early 90s tracks…
Some of this is specific to Ableton Live but it doesn’t have to be.
First, start the track as usual, which in this case means use Push in more or less the “standard” way: get a bassline going, duplicate scene, add hi-hats, duplicate scene, add kick + snare, duplicate scene, add strings… and so on.
Then mess around with it finding good combinations of scenes and clips so it starts to sound like a song. Get an idea of how it should play out. Add “performance” effects here – stuff that’s not really targeted at mixing: delays, sweeps, whatever.
Start recording the session to arrangement mode, and run through the performance that’s been developing. Make it longer deliberately so sections can be cut out easily (if you like – maybe there’s no need?)
Possibly add some mixing type effects to the tracks in arrangement mode.
Record each MIDI track in the arrangement to an adjacent audio track, not necessarily with the effects in place.
Now it gets weird: record each stereo wave track to cassette around the 0dB mark, then immediately record it back in from cassette to another stereo wave track. If you have a 4-track, do two tracks at a time; with an 8-track, do four.
Once these newly “degraded” tracks are in you’ll probably have to do some lining up, but that’s another of the naturalistic effects we’re after. You might (will) end up with some micro-phasing artefacts which may or may not be interesting.
Now you can mix down with a combination of pristine stereo and cassette stereo tracks, even giving us the possibility of sliding from one to the other. How about making a track fade continuously from cassette to pristine as the track goes (or the reverse?) How about widening the stereo of the cassette track and narrowing the stereo of the digital? And so on and so forth…
This is one of those things that you just wouldn’t expect to be so damn difficult: create SubRip .srt files for videos. My main use for this isn’t to subtitle foreign speech, or create subtitles for the hard of hearing. Rather, I just need to caption screencasts and I’d rather make it more accessible than printing text onto the video in ScreenFlow. I have use cases where it’d be very helpful to be able to do both Spanish and English captions and the user to get the one they need automatically. A lot of these screencasts are shared via Google Drive, so the YouTube-style captioning works well – *if* you can create the SubRip files.
There are tons of pretty awful apps out there for this, but I couldn’t find a single one that I would actually *want* to use – and that worked crash-free, with the video format I’m using, etc and so on.
For some reason, I hadn’t noticed that ScreenFlow can handle all this *in situ*. (Yes, doh.) It isn’t the smoothest implementation ever, but it’s usable. I don’t know why they don’t just allow the start/end times to be dragged, but there is a keyboard shortcut for it. Also, the caption track doesn’t work if there’s no audio in the project, which is annoying. Anyway, at the end of it, the SRT can be exported and on the one small test I did, works perfectly.
Maybe I should clarify my [earlier post](http://domi.co.uk/2013/05/17/adobe-creative-cloud/) where I complain about Adobe Creative Cloud. At that point, the file-syncing part of the cloud just didn’t work with no explanation of why (or *if* – so we couldn’t tell if it was my dodgy internet connection or what.)
Right now, the new Creative Cloud app is much better, and lists the file syncing as “Coming Soon”. Maybe they should have done that with the original implementation.
App install/update seems to be considerably better than before. I’ve yet to really look at Behance.
Flickr being not very helpful. Apparently I uploaded a “restricted” video… can I get them to answer me on *which* video? No. So, my photos become invisible unless you log in to Flickr. (i.e. *useless*)
Time to move on after 10 years of Flickring…? Maybe.
**Update:** maybe some G+ for the personal/sharing stuff, and Behance for the “pro” stuff?
It’d be nice if it worked.
We all dig some serious bass these days – given that my favourite artists are funkers, house acts, synth wielders in general – I certainly do. But it seems like I’ve been listening to a lot of music that consciously avoids clogging up the bass recently. Even more oddly the artists are conspicuous for their bass deployment: Bootsy, Prince, New Order…
In the case of Bootsy, if you pick almost any Rubber Band track, the low-end is occupied more by the drums – toms and even chunky snares as much as kick – than Bootsy himself. It also leaves a niche for Bernie Worrell to insert his unique lines. Everybody’s favourite funkateer lands above it with the extra high frequencies of the distortion and Mu-Tron sweeps, quite apart from the fact his lines are often clanking around higher frets anyway. That last point is generally agreed to be the defining sound of Joy Division and New Order: Peter Hook’s home territory of the top half of the neck. It still clunks nicely, but it leaves plenty of space for a DMX or acoustic kick – or a deep, pained voice in the former case. And when Prince’s *When Doves Cry* came on the radio in 1984 it stood out a mile – because it’s amazingly crafted pop, but also because it doesn’t sport a bassline at all. The Linn had all that space to work.
Although it’s a truism and/or cliché to say that the first rule of SEO is to write good content, it’s probably also been said somewhere, at least once – I haven’t *searched* for it so I don’t know – that thinking about SEO while writing your good content makes it even better. By which I mean that if you’re thinking consciously about the core meaning of the whole piece while writing every sentence, you end up staying more on topic and writing more useful content. Maybe people who actually know about writing already do this? I wouldn’t know!
> This is another of those “note-to-self” posts, where I detail how I’m setting something up so that I can refer back to it, or so I can point someone else to it. As if often the case, some of this may be Debian-specific…
There are different ways of approaching the task of setting the permissions for web directories, depending on how many users have access to the server, how many sites are sharing the server, and lots of other concerns. I tend to be in a situation where anyone who has shell access to the server is at a level trusted with web content, so that simplifies the process somewhat. I’ll look at different levels of dealing with this questions, in increasing levels of security.
## Simplest approach: use the `www-data` group
This is the default group that Debian has for web daemons. If you add everyone who can log in to this group, you can then use this group for all web directories that the notional “web team” needs to access, and make them “group writable”. **Be aware that this configuration also allows the Apache daemon itself to write to the web directories, which is an obvious potential security issue, so you need to be sure that the web applications in there don’t/won’t allow that.**
You can either specify the group when creating the user:
adduser –ingroup www-data USER
or add an existing user to the group:
adduser USER www-data
## Almost as simple as simplest approach: create a `webdev` group
This is also a very simple approach, which won’t allow Apache to write to the web directories, unless you specifically allow it. (This would usually be for cache directories, image upload and so on.)
“webdev” is just an arbitrary name, it can be anything you like as long as it doesn’t exist. First create your new group, then add the user(s) to it:
adduser USER webdev
It goes without saying (or should do) that for the above to work, you also need to allow the right group access to the web directories you need. A simple example of this, making a few assumptions of your directory layout, would be:
chgrp -R webdev /www/www.example.com/htdocs
chmod -R g+w /www/www.example.com/htdocs
So what did we just do?
First, we recursively (`-R`) changed the group to be `webdev` for the `htdocs` directory. Then, we (also recursively) allowed the group write-access (`g+w`) on `htdocs`. Which means: from now on, anyone in the `webdev` group can create and edit files in `htdocs` and any of its subdirectories. Note that these lines will stop any previously configured group-access from working (if it’s a different group from `webdev`). However, if we have a directory with write-access for everyone (AKA “`chmod 777`”) as is sometimes the case with cache directories, for example, they won’t be affected.
So, how can we make this more granular?
## Multi-layered approach: create per-site groups
If we wanted to have some directories writable by all our web team, and others by certain people in certain sub-teams, we can create multiple groups.
Take, for example, two subdomain sites on example.com: foo.example.com and bar.example.com. Of course, these could be different domains, I’m just sticking with example.com for the, er, examples. We want to deny editing access to the teams working on these two sites to each other’s site. A solution is to create two groups: `webdev-foo` and `webdev-bar`, maybe.
adduser fooguy webdev-foo
adduser foogal webdev-foo
adduser barboy webdev-bar
chgrp -R webdev-foo /www/foo.example.com/htdocs
chgrp -R webdev-bar /www/bar.example.com/htdocs
chmod -R g+w /www/foo.example.com/htdocs /www/bar.example.com/htdocs
This takes care of giving write-access for their sites to `fooguy`, `foogal` and `barboy`. Neither `fooguy` nor `foogal` will be able to write to the bar.example.com site’s directory, and `barboy` won’t be able to edit foo.example.com. If we want to allow all three of them to edit or create inside the main site, we just add them to the `webdev` group, assuming we’ve already set the permissions for its root directory and children to be `g+w`.
adduser fooguy webdev
adduser foogal webdev
adduser barboy webdev
## Checking permissions
If we pop over and have a look at these directories, what should be see?
ls -l *example.com
The output should be something like:
drwxrwxr-x 2 root webdev-bar 4096 2012-01-09 18:49 htdocs
drwxrwxr-x 2 root webdev-foo 4096 2012-01-09 18:49 htdocs
drwxrwxr-x 2 root webdev 4096 2012-01-09 18:50 htdocs
What does that mean? What we’re seeing here is that in all cases, the permissions are set as `drwxrwxr-x`, which means:
1. It’s a directory
2. User permissions are `rwx` – Read/Write/eXecute
3. Group permissions are also `rwx`
4. Other (“world”) permissions are `r-x` – Read/eXecute
We can also see that each of the `htdocs` entries has `root` as its owner, and the respective group we set before as its group. If we’ve already got a super simple site in these – just an index and an image directory – and list inside of htdocs, we should see:
drwxrwxr-x 2 root webdev-bar 4096 2012-01-09 19:01 img
-rw-rw-r– 1 root webdev-bar 0 2012-01-09 18:59 index.html
drwxrwxr-x 2 root webdev-foo 4096 2012-01-09 19:01 img
-rw-rw-r– 1 root webdev-foo 0 2012-01-09 18:59 index.html
drwxrwxr-x 2 root webdev 4096 2012-01-09 19:01 img
-rw-rw-r– 1 root webdev 0 2012-01-09 18:59 index.html
This tells use that the index and the directory are both editable by the right groups as well. (Files are `-rw-rw-r–`, meaning user and group read/write and world read-only.)
*To clarify: “execute”, when applied to directories, means the ability to change into it or open it. Applied to a file, the execute-bit is a potential hazard, if the file has any code in there, but that’s another story for another day.*
## More granularity: ACL
The approach detailed above is usually enough for most web situations, but if more control is required, we move into ACL territory (Access Control Lists). This is something that has to be made available at the filesystem level, and isn’t usually available on normal web hosts. As such, it’s a bit out of the scope of this post.
When I got my SSD installed in my MacBook, I swapped out the (defective) DVD for a caddy from Mac:Upgrades to house the original boot drive. This was completely unrecognised, but I didn’t have time to worry about it, so put the old boot disk in an external FW400 case and used the data from there. I assumed there must be something wrong with the ATA interface on my MacBook’s motherboard, which could explain the DVD not working.
Long story short, I popped open the MacBook and another almost identical one with working DVD and tried all the combinations of disks I could. The odd result of this is that the original boot disk was the only one that didn’t work in the caddy – every other drive I tried worked. Very odd. Anyway, I just put a different drive in the caddy and used its external case for my rebellious original boot disk. I can’t think of an explanation for that set of circumstances…