You searched for entries containing the word "keys".

Matching entries are ordered according to their relevance and not the date they were posted.

BTW, I got the keyboard for my birthday in the end. I also got Resident Evil 4. So far the former has received about half an hour of my attention and the latter about 11 hours. I'm warming up to it :-).

I'm alone. It's completely quiet. Even the builders next door have shut up for once. All I can hear is the whine of my laptop and the sound of the keys. After being in the bustle of Manhattan and with Louise every moment for almost 2 weeks, it's sad to be alone in the quiet.

I think I may have to get a job just to get some friends.

The admin page takes ages and ages and ages to load. This is because it's loads of stuff lumped into one page. The solution is modularisation. The site needs a proper Admin _AREA_ instead. Modules include:

• Messages
• Users
• Threads
• Files
• Themes

Plus any others that turn up in the process of redesign.

The completed version needs to be secure as well, although I can't see why I need to go much further than the PHP user login combined with the htaccess password.

Off-topic, the WAP microsite needs a complete rethink also. It's probably possible to get PHP to encode the session keys into link URLs, thus providing better security without cookies. God I hope sessions fix all my log-in troubles, God knows I haven't got any better ideas.

Been playing around with Chuck, a realtime audio programming environment, again. Got a bit further this time, i.e. as far as playing a sample and doing some other bits and pieces. Not very close to making anything that you could call music yet though.

I had the honour of being the first person to post to the mailing list, I hope they are responsive, as close contact with the developers is going to be pretty much essential given the rough and ready state of the documentation.

I found out that Chuck is a project of Perry Cook, one of the guys behind the Synthesis Toolkit (STK) which is a C++ API for sound making. I had a play with this last year. This is a good thing as STK is very powerful and contains lots of interesting audio potential. Chuck and STK are already integrated to a limited extent, but one would expect to see more STK stuff going into Chuck.

As regards the whole idea of programming music machines on-the-fly: it's tricky! Even with some pretty frantic Vimming, there's still a lot of time lost. Compare this to playing Ableton Live with keypresses and mouse scratching. I suspect that a successful programmer/musician will have to make a lot of use of high-level language features. Chuck's .lex file seems to indicate that there is (or will be) support for functions and even classes. I wonder if it will be possible to create a class instance within the Chuck VM and modify it whilst it runs from other code. That would be handy, but would require some kind of central object model.

Another idea was that it would be handy to have a Python-style toplevel interpreter. For example, if I set up shred playing a loop, a bass-drum, I might want to suddenly change the interval between hits, and then almost immediately change it back again. For example, to do a rush at the end of a quad of bars. Creating a new text file to set the interval one way and then another text file to set it the other way and then doing replace operations on the VM is annoying. Chuck usefully allows you to access the VM from within code, so you could set up a script which automates this, but say you don't want to automate it, say you want to play it by ear (literally). With a toplevel you could define library code so that these changes require only single line instructions and then play them much more easily.

Maybe what Chuck really needs is someway to associate functions and code with time ranges. Some way of saying, in 8 bars time, run this bit of code. But that would still be limiting. I find performing to be really self-referential, I play around until I hit something I like, then I repeat that. Chuck needs to allow much easier and more rapid prototyping of musical ideas. Sadly, I'm not sure that code is the best interface for this. When playing with Live I very much appreciate being able to latch on to a control with my mouse and then jam with it. And also be able to hit keys to play samples at the same time. Even the most deft master of multiple terminals couldn't do as well as that. But then maybe this is a style issue. Maybe I jam in real-time because I'm not actually a good enough musician to get into the deeper stuff and I'm limited to making funny noises on top.

In Part XVIIII of Afternoon Attacks the Web Community with a Cudgel, I pick on designer and writer Curt Cloninger. Curt is the author of the excellent Fresh Styles for Web Designers, the only book on web design I own.

I explained my crusade, albeit not very well, and he had some interesting points to make, not least this:

So why, if I'm doing a design-centric, low-text site, do I care about being standards compliant? The standards aren't made to accomodate the kind of work I'm doing anyway, and they never will be.

I just think of standards as the walls of the room I'm in, whereas of course it's actually the browser implementations of those standards that make up the walls. I disagree though, standards are important to every developer because the web is young and imperfect medium and it's the standards that are going to push it forwards. That's why I'm concerned in many ways, because I see the web being pushed forward with semantic purity, accessibility and usability the only goals, engendering a rather dull, almost Victorian, experience totally in contrast to our "everybody's having sex right now but you!" OTT culture.

One thing I noticed is that Curt mentioned the whole Tim Berners-Lee High Energy Physics thing. Everybody, no matter which team their on, mentions this. Strange. I have been thinking anyway that my idea to start the ALA article out with a bit of history is probably redundant since everybody knows it already. I'm getting less sure about my article day by day. What am I actually saying?

• CSS really great, mainly
• Tables bad, complicated, old, semantically useless
• Web design hard, medium has little control, people (esp. clients) demand faithful reproduction
• Fluidity is one of the keys to success, allows people to do cool things like bump their text sizes or turn off images or resize their browser to 1 pixel square whilst retaining perfect layout
• Overall, tables better at fluidity than CSS
• But tables bad

• Need new thing!

  • Is fluid
  • Predictable
  • Easy to use, painless for as many layouts as possible
  • Good for both coders and DW-monkeys
  • Complimentary to and logically consistent with rest of CSS
  • Similar to tables for reasons of application and implementation
  • Contains advanced syntax for specifying how the layout adapts to different devices or browsers
  • Allows author to specify ways for things to change
  • Allows author to know the frame of reference so they can always do something cool with it

Curt also pointed me in the direction of the Dao of Web Design, a really good ALA article about living on the web, building pages that are flexible and that work for people. I don't think I've been making this clear when I've been hassling people, I certainly didn't make it clear when I wrote to Curt, but this is the big thing for me. Pages have to fit the end browser, in terms of size, font, everything, that's got to be the way it is and that's where CSS is lacking IMHO. Grids aren't great for this, which is why they should be able to reconfigure intelligently. Though working out a syntax to express all this is probably an NP-complete problem. The more I think about this, the more I think I should have been doing this five years ago, when I said I would do something similar for my degree final project and then smoked a bunch of weed instead. This is the kind of thing that would be a cool PhD.

next page →

Choose another page: 2.

Last updated at 0:35, Monday December 1st, 2008. All times are shown in 24-hour clock format and are GMT.

Rate my journal on bloghop.com: