Spanspek

Does anyone else think ebay Australia's new summary pages and searching are awful?

I don't have screenshot so I can't illustrate the difference. However, take a look the musical instruments summary page. The "sub-categories" used to be listed with the number of items on offer in each. That was useful because if one noticed that the number of items had fallen, I might decide that there were few, if any, new items to look at. Now I have to open the listings to see the total number of items.

Certain "search" pages have tools to narrow the number of items based on criteria related to the category. This is good. However, the "new" search tools allow the user to choose only one criterion, or to open a "choose more" panel (via an AJAX call). The whole thing is now a lot slower and requires many more page loads than used to be the case.

You'd think ebay would want to reduce the number of page loads per user. After all, fewer page loads means less stress on the servers (or more users before a server crashes).

For example, I'm looking for a new (well, new for me) laptop. Here's the laptop search page. Take a look at the left sidebar with the search tools. Wouldn't it be great if you could select multiple criteria right on that page instead of doing multiple page loads or clicking "Choose more" and then having to click through an AJAX-loaded interface to select your search criteria?

As with everything on the internet, your mileage may vary. I think it sucks.

I went to a Pro Tools 8 demo at JMC Academy on 8 April. It was run by Digi techster Brent Heber.

There are lots of improvements over Pro Tools 7:

MIDI Editor:

• Multiple tracks in one view—events are colour-coded
• Editing looped or duplicated MIDI segments alters all iterations

Score Editing:

• MIDI editor has a score editor mode
• print mode for editing printed scores
• can export Sibelius (.sib) files, but can only read MIDI files—WTF?

Virtual Instruments:

• Vacuum—monophonic, dual oscillator synth. Has about half a dozen overdrive controls for distorted everything!
• Xpand now responds to up to four MIDI channels
• Boom—a grid-based beat box editor like the old TR808 sequencer
• Mini Grand—sample-based piano with a 900MB library and reverb effect
• DB33—a Hammond-style organ with a cabinet effect that can take an external input
• Structure sample player now allows one to drag and drop regions from audio track playlists. Different versions (free or paid) have different features

Plugins:

• all the usual DigiRack plugs with a true stereo EQ3,a new version of Sansamp, new algorithms in D-Verb
• some plugs previously available for money are now free: DFi and Maxim
• Eleven—guitar simulator. Different versions (free or paid) have different numbers of amps and tones

"Comp" edit workflow is much improved:

• Loop recording takes can be in one file (as before) or in separate playlists (new preference setting)
• If in separate playlists, those playlists can be displayed in the edit window below the "main" playlist
• Can copy selection of region in comp playlist to main playlist

BUT...

Digi still hasn't fixed the loop record to include pre- and post-roll in the loop. As before, pre-roll is played before the first iteration of the loop and then only the selected part of the timeline or playlist is looped. I've been asking Brett about this since version 6. For those times when the context of the punch-in is important to the performance—most of the time—loop record is useless.

All in all, it's looking pretty good. There are still things one would like to have, like removal of the 18I/O limit in LE, but Digi has demonstrated time and time again, that they won't do anything that would poach the HD market, and they still don't provide an upgrade path with any "middle" ground between LE and HD. It sucks, but what can you do when they have the market power?

My re-write of the Stageplan app is going well, despite the fact that I have little time to do it. So I'm posting a demo here. It uses Raphael 0.71. I had some difficulties with this, but have solved them, albeit somewhat inelegantly.

Click on an item and drag it onto the "stage" area. When you do, a slider control appears. It allows you to rotate the object. When multiple objects are on the stage, clicking on any one of them selects the item shows its slider control. When you click on the stage, a selected item is deselected and its slider disappears.

I've added an "amplifier" object. I should also add a DI box and a keyboard as these are regularly specified by students in their stageplans. Other items, such as the drumkit and piano, tend to be static (as they are difficult to move). The latter can probably be added to the stage as partly opaque objects.

Here's the demo.

The next step is to figure out how to save objects on the server so that stageplans can be recalled, viewed and edited. Bolt on an authentication system and it'll be done!

It's been some time since I worked on the application that would allow performance students to draw stage plans for their performances. As I mentioned previously, I'm using Raphael, a Javascript drawing library which uses SVG or VML.

There have been several revisions of Raphael since I last worked on the app, so when I upgraded I found that I could no longer clone image objects. The reason turned out to be that calling myImage.attr("href") no longer returns the URL of the source image. There is now no easy way to do this. Dimitry or one of the other contributors has added a "src" attribute which is easily set (for changing the image source of an object) but not retrieved. Since my cloning method relies on retrieving this value, I was stuck.

When I looked at the Raphael source code, I figured out a way of doing it, but it's clumsy:

The app works like this: If you click on a tool, the tool is cloned as an "item". If you let go of the mouse button while it's still over the "palette", the clone is deleted. When you drag the item onto the stage, a slider for controlling its rotation appears. Clicking on the stage "deselects" the item and its slider disappears. Clicking on an item shows its slider with the slider thumb showing the previous degree of rotation. Moving the slider's thumb rotates the item. Clicking and dragging the item moves it around the stage.

I took the opportunity to refactor the code and rewrite almost all of it from scratch. There is now an object for each tool and for each item created, as well as the slider which controls the rotation of the selected object. It's not very nice OO, as there are explicit references to the "palette" and "stage" in Tool and Item methods, particularly for assigning event handlers to items. However, for a reasonably experienced PHP programmer (with a smattering of assembly code, Basic, Pascal and C on the way there), Javascript's lambda functions and closures and the consequent effects on variable scope seem quite weird anyway, so I'm not going to lose any sleep over it!

In a day or two, I'll post a demo of the work done so far.

This post is not, as you might imagine, my opinions about what the developers of Habari ought to do next. Rather, it is about what I must do to make Habari suitable for podcasting of music and classes at my workplace.

As I stated previously, I wish to have my students record some classes and music performances for podcasting. Habari has a podcasting plug-in which handles uploading of files and modifying the Atom feed accordingly. I have yet to play with that properly, but it seems to do what I need. I was going to use Feedburner, but the need for that is somewhat less now that the plug-in can insert the apparently necessary iTunes-namespaced elements. As iTunes is almost the only game for subscribing to podcasts, this is probably sufficient.

The other requirements for this application are:

1. Students should be able to create entries and upload MP3 files.
2. Only staff should be able to publish entries.
3. Students should not be able to edit entries after they have been published
4. Students should not be able to add or configure themes, plug-ins, or other options, or import entries from other blogs.
5. Students should not be able to add, edit or delete other users.

Number 1 is achieved with the current users and groups permissions system. Number 4 is taken care of by the permissions system. Number 5 is not quite taken care of by permissions.

Numbers 2 and 3 need to be done with custom actions in plug-ins. I have created a plug-in which I call Publisher. It intercepts various actions and modifies them.

For example, if the user is a "student" rather than an "administrator", it modifies the administration menu beyond what the group permissions system does to allow a user only to edit his or her own details. However, removing other options is not sufficient as a user with a knowledge of Habari's URLs could type the URL for any of those options directly in the browser's address bar and access them directly. So my plug-in also restricts this access and redirects the user to his own details instead.

The plug-in also prevents non-administrative users from editing posts which have been published and removes access and links to editing published posts. I have examined various of the plug-in hooks but the only I have been able to find to remove "edit" links is to filter the 'include_template_file' hook. This povides a means of including custom template files. It would be better to intercept elsewhere as this hook applies to any template file loaded by Habari, not just those forming the admin UI. I'll work on finding a better solution later. For now, let's just say that not all hooks are documented.

The same page of the admin area that I'm trying to modify also includes a way to delete posts. Despite the groups permissions system allowing editing of one's own posts only, deleting any post is possible regardless of one's privileges. If the Undelete plug-in has been activated, the deleted post can then be edited and saved as a draft by a non-administrative user. (Keep in mind that a user in the "student" group—a group that I created— should not be able to edit any posts but his or her own.) This anomaly might have been fixed in subsequent builds. I must check it out. (It's currently revision 3286, whereas I'm using revision 3137.)

I also have to work on a theme for the podcast and, as I'm not a designer, this could take some time!