Project Kyūdō

The theme teams are doing a good job now on a few community themes. But for Jaunty and following cycles, the Ubuntu artwork community could do a better job.

My allies and I would like to push things towards a solid design process.

One that starts with the question what it actually is what we want to achieve, what our message is and who we are addressing. Goals we can agree on and that will lead us through the design, helping us to collaborate in a larger team in a meaningful way.

A process that will lead us out of the shadows of purely personal opinion and hidden assumptions towards the light of reason.

A process where we will not jump unto the first idea, but develop and test several designs for each little part. Where we will not restart on the next cycle, but build upon the existing. Continuous refinement.

One that will offer anyone a chance to learn about design in a deeper way and that will show onlookers that we are damn serious while we enjoy
the ride!

https://wiki.ubuntu.com/Artwork/KyudoGuidelines

Discussion is under way on the ubuntu-art mailing list. Questions and feedback are of course also welcome here :)

Containers

What if a NLE/sequencer would use tracks only in the sense of having rows to place stuff on, tying all routing and parameters to objects in the timeline?

You would have a lot of flexibility. It would become easy to apply effects to specific regions. You could just import sessions and chain them in a master session. But if being able to set everything on a per object basis becomes having to do so, things become cumbersome.

There could be containers for wrapping objects. Objects could inherit settings from their containers.

For an NLE, audio steams, video streams, automation data, processing nodes (plugins) and connections could all be shown as objects on the timeline. Connections as separate objects means they wouldn’t be tied to the lifespan of source or destination.

A very basic example of how this could look like:

The first container defines a time reference, position and transport state (paused or playing, relative speed). One case where you might want to use 2 transport scopes would be video within video, being able to change the speed and playing direction of the embedded video (here I assume each transport scope is fully automatable).

Since the horizontal axis is taken for time, nesting must be expressed vertically. Think of Lisp-like parenthesis ;)

The slider after Group is just to show that controls could be placed on container headers.

A concept for showing detailed info and options for all objects that cross a location (could be the playhead or a marker):

The basic idea is actually years old, but I had to think of this again because of the Lumiera project.

Work on Ardour export started

It has been a while since I wrote that document about a better export dialog for Ardour.

Now Sakari Bergen takes part in this years Finnish Summercode project, improving export functionality based on my work and adding meta data support. It feels great to have a competent programmer realize my concepts (especially compared to struggling along to get just a tiny demo implemented myself … ;)). I’m looking forward to the results. We have been chatting on IRC and I’m ready to assist him where I can.

Idea Promotion

Now i can’t resist trying the brainstorm image links! ;)



Have a means to configure shortcuts for all installed applications in one place.

This way conflicts become obvious and can be fixed or avoided easily. Identical and similar actions can be assigned the same shortcut across apps. It becomes feasible to change shortcuts for common commands like Save or Print.

There could be sets of shortcuts adapted for use by right or left handed people, people who can’t use some fingers or an entire hand.

JACK Synthesizer Manager Proposal

Audun Halland and I have been thinking about a set of related problems in the realm of Linux audio. The first result is the following proposal, meant to gather feedback from the community via the LAD and LAU mailing lists.

JSM, the JACK Synthesizer Manager

We propose a programm that acts as a proxy between sequencing software and both software and hardware sythesizers. Among the goals are unified patch selection and making projects more portable.

If we get the impression that the JSM is something that both developers and users will find handy and use, then development might start real soon.

In this text, we avoid going into technical details to foster free thought and discussion.

Use Cases

Patch selection

Goal: Choose patches from all available hardware and software synthesizers.

Giorgio uses a single means to select a patch among all patches of all of his software and hardware synthesizers. He uses meta-data to find the right patch. The right connections are made automatically.

Computer as syntheszier

Goal: Use the computer as a compound synthesizer in a live performance.

Hiromi has her keyboard connected to her laptop live on stage. She uses several soft-synths via keyboard-split and layering. A few selected parameters are bound to the wheels of the keyboard. After each song, she switches from one setup to the next with least effort.

Collaboration

Goal: Exchange projects without having to change settings back and forth.

Alice and Bob take turns on working on a project. They use different hardware but don’t have to manually change connections and choose patches on each turn because of an abstraction layer.

MIDI Interface Ports

The problem with MIDI interface ports is that the hardware on the other side and its setup might change. Or be entirely different if people exchange projects. An abstraction layer can make this more comfortable to handle.

The JSM takes care of the mapping between software ports and MIDI interface ports. It can work on a per MIDI channel level.

Patches and Instrument Definitions

Patches and controllers are chosen by name; the user doesn’t have to deal with cryptic numbers. For kit-programms, name mappings are given (e.g. bass drum on C1).

Patch selection happens by a single means, offering all available patches (JACK apps, plugins, hardware). Making the required MIDI and audio connections is automated as far as possible.

Categorization

Categories help to find the right patch among many. When exchanging projects, they help to replace unavailable patches with similar ones.

Virtual/Compound Synthesizers

From the outside, the computer can be dealt with like a single compound synthesizer. Different synthesizers can be triggered from ranges on a single keyboard (key splits). Synthesizers can be layered. The whole setup can be switched with programm changes.

JACK to ALSA Bridge

JSM could be the de facto JACK MIDI to ALSA MIDI bridge. No Jack “SYSTEM” midi ports, the jack world only sees the devices offered by JSM.


Audun Halland and Thorsten Wilms

A Look at the Ubuntu Installer

In one handy PDF Document. Issues, suggestions and mockups.