Charmed Quark Systems, Ltd. - Support Forums and Community

Full Version: What I have learned in programming a UI to select and play music
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
After reading the docs and programming the UI, I though that I would write down what I learned. (And many others have done before me, and more will do after me)

Terminology:
TITLE: a collection of 'collections'
Think of a box set:
CDs: Best country 1950-1980 (with 12 CDs in the box)
Movies: Alexander, Directors cut (2 DVD's in the box)

COLLECTION: a single DVD disk or CD disk

ITEM: a single track(song) from a CD, or a movie chapter from a DVD

The rest pertains to music, but movies are similar.

ENQUEUEing: put stuff in a list to be played later by a player
PLAYing: start playing stuff directly by the player

In order to play music, you need to have media, and a player.
The media is in a repository, which can be internal to CQC, or which can be imported from an external program (itunes, ... )
The player can be internal (CQSL Audioplayer) or external (Zoomplayer, ...)

In the UI programming, you have 2 kinds of widgets:
"Media Repo XXX" widget and "Media XXX" widget
The media repo widgets get their information from the repository, the Media widgets get their information from the player.

Let's look at the "Media Repo XXX" widgets first
A. Media Repo Text lets you see all kind of attributes of a certain set or collection:
B. Media Category Browser (I know, misnomer)
lets you select the category from the repository that you want to see
(Rock/Folk/Audiobook/... )
C. Media Repo Image lets you see the cover art of a Collection
Title/Year/Artist/Runtime/...
D. Cover Art Browser (also misnomer)
lets you browse your repository.
E. Media Repo Item Browser: lists the tracks(=items) in the selected CD(=collection)

In the UI, there is a new item in the pop up menu that lets you generate a repository browser in one click!
It links the following: a cover art browser, and a media category browser, and a toolbar that lets you jump around in the shown selection.
Additionally, with sending commands to the cover art browser, you can order your shown collection by Artist, by Album name, and by Year [ last one is not fully implemented ]
You can further narrow your show sets/collections by setting the category, or by jumping to a beginning letter.
For example: show me all sets/collections in Folk, sorted by Album name and starting with the letter Q or later


Now for the "Media XXX" widgets
A Media Image: get the cover art from the currently playing title/collection
B Media Item Browser: lets you see and rearrange the current tracks that are in the playlist queue

In order to work with all of this, you need to consult the following documentation: CQC User Interfaces (Interface Development Guide) which you find under Learn->Technical Documents
The documentation for the player which you find under Learn->Supported Devices->Media Players
and some videos like Learn->How To Video's->Media Repository Configuration
and Learn->Tutorial Video's->Graphical interfaces->Toolbar
(and pretty much all other videos under the graphical interfaces)

In order to know how to program a widget, you need to take the following into consideration:
- you should name your widgets, since that is how you can send them commands.
- widgets have settings that you can configure in the attributes pop up menu
- widgets can receive commands: in the CQC UI manual, they are listed underneath the widget description as "commands accepted"
- widgets can send commands to other widgets and drivers. Sometime these need special arguments, and those are called Runtime Values. The runtime value that a widget provides are listed under the widget description as "Runtime Values Provided" the typically look like MediaRTV:xxx or StdRTV:xxx
- drivers (like the audioplayer) can recieve commands. You do this by writing values into their write enabled fields (W or R/W). The list of fields in documented in the driver description. The values are frequently the RTV values from above.
- drivers give information. These are available by reading from the read enalbed fields (R or R/W). The list of fields in documented in the driver description.


Widgets need sometimes information when you first create them.
This is typically done by filling in the tabs that describe the widgets. For example which repository they are linked to (when loading the UI).
They also may need information on what to do when they are clicked on. That is in the actions tab. This is where they will send commands to other widgets or drivers. It is probably the most important tab in every widget description (together with the name in the Widgetname in the Basic tab)

Two remarks about programming the UI:
- save often! sometimes the UI editor will quit with a fatal error without giving you the chance to save. You can hit ^S to save your current template, or there is a menu item for Save and Save All
- Think about the name you are giving your widgets. Go for something descriptive. You will find out very soon that it is EXTREMELY tedious to change the name of anything afterwards in CQC! This also goes for the monikers, the names of your templates, basically anything with a name

Feel free to comment on this, I will try to edit this post to reflect these corrections/additions.

TO BE CONTINUED
Stefand, thanks for putting it in plain English for the non programmers like me Smile
Quote:- save often! sometimes the UI editor will quit with a fatal error without giving you the chance to save. You can hit ^S to save your current template, or there is a menu item for Save and Save All

If this happens, let me know. We can set up your editor so that it will generate an error info file that you can send to me and we can figure out what's going on.

In the start menu item, add the following parameter to the editor's command line:

/TraceSev=APIFAILED

If it happens, then send me any .ErrorInf files that show up anywhere in the Logs or Bin directories. You might want to clear them out periodically since this will cause some things that aren't actually errors to generate them.
Will Do .
Quote:save often! sometimes the UI editor will quit with a fatal error without giving you the chance to save.

I dont remember having a fatal error ever. Is this something with the new version?
It's probably specific to some set of circumstances, so some will see it and some won't. We just need to figure out what those circumstances are.
OK, I think I see the issue, or at least the one that Simon had. If you right click on an editor window, and it's not the active one, it doesn't get activatated, but you get the popup. So you can then delete a widget and it tells the widget palette to delete that widget, but it's not the right one, since the widget palette is still referencing the active editor window. So now the widget palette is out of sync with the active window.

So I just need to force the editor window forward if you right click, in addition to if you left click.
mine crashed twice yesterday and I didn't have "/TraceSev=APIFAILED" activated. :-( ... def save often as when I reopened it I lost the last hours work.
Dean Roddey Wrote:OK, I think I see the issue, or at least the one that Simon had. If you right click on an editor window, and it's not the active one, it doesn't get activatated, but you get the popup. So you can then delete a widget and it tells the widget palette to delete that widget, but it's not the right one, since the widget palette is still referencing the active editor window. So now the widget palette is out of sync with the active window.

So I just need to force the editor window forward if you right click, in addition to if you left click.
Yes, I definitely think it has to do with right clicking on a non active (Backwards) window.
Quote:mine crashed twice yesterday and I didn't have "/TraceSev=APIFAILED" activated. :-( ... def save often as when I reopened it I lost the last hours work.

What were you doing at the time?
Pages: 1 2