Media

inovative concepts for Media in overal Haiku design

Posted Fri, 2009-04-24 22:20 by zblace

In reading some of the posts on R1 and R2 (especialy in regards to the quality of user experience) I realized that maybe more conceptual and inovative approach would to OS media design experience would also be attractive for first time users.

For example - just like using vector graphics (especialy in icons) that would make the interface scale and look better, it would be also interesting to use procedural/generative media...for example instead of delivering single quality fixed sound files it would be great to have them generated on the fly with SuperColider
(http://en.wikipedia.org/wiki/SuperCollider).
In this way one would be able to avoid hearing always the same sound when booting the system - but instead hear a tune that is not only variable, but also unique to his system (especialy if it uses system info to render specific sound)...that way it would be similar to the ida of older cars - when you could actually hear the engine (unique sound for each car) and by doing so becoming aware if all things are OK or there is something wrong.

Please take time to hear few examples of simple generative sound code from this webpage http://supercollider.sourceforge.net/audiocode-examples/

I am sure similar concepts could be developed for other parts of OS that would be inovative for system design, as well as make HAIKU stand out for it's quality/sophistication - rather then quantity of features.

Realtime Audio Normalisation

Posted Sun, 2006-08-20 16:00 by admin

Haiku could benefit from implementing an automatic real time audio normalization system (i.e. An automatic volume adjustment system) at the mixer level on a per channel basis. It could utilise adjustable normalization schemes based upon given scenarios or channel purposes.

Details

Real time audio normalization could be implemented at the system mixer level in Haiku. This system would be designed to boost or soften sounds produced throughout the system to suit listener tastes or given conditions. E.g. Large quantities of digital media have extremely low sound levels throughout. But it is also impractical to continually adjust the volume of the player application. With this system in place, the digital media's volume could be scaled to an acceptable volume, while not affecting other audio playback applications in the system or requiring user intervention when switching to digital media with appropriate audio levels.

An easily accessible volume range setting, incorporating a maximum volume and a preferred volume would be ideal. The maximum volume setting should be exactly that. No sound should ever break that level, primarily for comfort reason, but also for added safety. (A DrDobbs column relates the story of one user with headphones playing soft music. They received an extremely high volume sound clip and was left almost deaf). The system should adjust the volume as closely to the preferred volume level as possible at all times, without ever breaking the maximum volume.

While this system will allow quite reasonable performance, the addition of normalization schemes would allow for greater control over sound levels. These schemes would encapsulate settings such as delay times, how quickly the volumes scale and how greatly the volumes scale. These schemes could then be saved and applied to different situations. For example there could be one for watching video which does not alter sounds such as a gun crack in a suspenseful scene, another for listening to music and another for TV designed to soften loud commercials. Schemes would be applied on a per channel basis, possibly using a "default scheme" unless otherwise specified. The direct manipulation of schemes should not be necessary for the system's use, it should be provided as a means for advanced users to fine tune rather than as a general tool.

The possibility of saving much of this information into attributes looks promising. It could be quite effective to store, for example, normalization schemes as attributes in each file of a users music collection, providing a customized normalization for each. This could of course be achieved similarly for all media and extended also into audio applications, saving the last normalization settings as attributes of the binary.

When considering system alerts and other such sounds, it could be possible to make use of a dynamic normalization scheme which could utilise information such as the current average volume. This way sounds from sources such as system alerts do not provide a great disruption to the user.

One way to implement such a system, would be to make use of VST plugins at the mixer level. Using a preset number of plugins per channel as well as for mixer outputs it would be quite easy to develop a normalization system with support from additional kits from Haiku.

Resources


Feature Wishlist

Posted Sun, 2006-08-13 15:25 by admin

This article was started by myself, but it was extended by our users when it was placed on our wiki. The development team will have to review and discuss all suggestions.

Multi-User

  • something similar to what Win2k does, where you try to do something and it says "you don't have permission to do that. If you are an admin, click here to enter the admin password for permission."
  • multiple users - One or many at a time? Security for many at a time?

New Kits

  • vector math library to use MMX/SSE/SSE2/3/4/5
  • What about having a synthesized speech kit. Applications would send text (possibly with special marks) to the kit. Particular languages could be available as plug-ins.
  • Voice recognition
  • Should we have help system? Pocket PC has very handy one, it's HTML-based. There's a folder somewhere, where your help files are (for example, StyledEdit.htm). When you have StyledEdit opened and you open help, it goes directly to the StyledEdit.htm file. When there's just an empty desktop and you open help, it goes to index (automatically updated links to files in help folder). So, whenever you install a program, the install script or package manager copies just one HTML file to the help folder. It's so easy to use, that OBOS should have it too. And there could be a simple search capability within the help files
  • synchronization kit - some sort of way to notify and automatically update subscribers when data changes
  • im kit
  • XML - possibly methods for BMessage to transform to and from XML, possibly a whole different kit
  • Encryption - a plug in architecture for encryption/decryption. Probably public/private key. With a key manager of some sort, so that it is easy for users. Also with a tie-in to the Mail Kit of some sort so that mail programs can quickly and easily encrypt and decrypt messages. Also a cache of public keys with methods to refresh them (via Networking Kit)
  • Database Kit - access for SQL databases will be a large sticking point to getting on the corporate desktop. The sooner the better. Look at SQLAlchemy for inspiration.
  • Fax support (kit?)
  • RPC (SOAP, XML, Web services etc.)
  • SpellCheckAPI
  • Reference kit (dictionaries, thesaurus)

Media/MIDI

Printing

  • Vastly improved printing is needed. Color management is huge, now, with digital photography. Additionally, more functionality is needed. Watermarks, more margin control, etc. All of those "extras" that you have on Windows and use once a year.

Device Kit

  • Why does serial port deserve a class but not BParallel? Or BAudioCD? Or BVideoCD? Or Scanners, Cameras, PDAs, etc? Every "thing" that you plug into your Haiku machine should have a class to access it.

Game Kit

  • Sprites, Backgrounds, collision handling, parallax, 3d, scrolling, tiling, AI, controllers (joysticks, etc) and more.
  • Translation Kit
  • How about 3D objects? Or vectors (structured drawing)? HTML read/write?

Mail Kit

  • public/private key encryption for email

UI

  • ditch menu bars for context menus only
  • we should go vector. And we should adopt SVG as our standard.
  • Dictionary of translated words, so that untranslated apps can be automatically (if imperfectly) translated.

How about being able to have a several applications using the same window, each one having its own tab? I believe there are UNIX window managers that do this though I've not tried them so I'm not sure how good it is in practice. I imagine there would be pros and cons.

Some GUI description language (XUL?) is a really nice thing to have in R2.

include a standard widget for toolbars, Some thinks I like about some toolbars:

  • drop-down buttons.
  • animated icons.
  • separators
  • options per toolbar - small icons, text under icon.
  • !!! configuration tool - add/remove button on the fly !!!
  • ability to collapse the menubar into a clickable icon for more screen space (maybe even into the tab?)

 

Additions to BBitmap - this class is really in need of a lot more "stuff". Think LeadTools for Windows - the ability to choose some area of the bitmap and apply transforms (plug ins). This has been done a dozen times for a dozen different art programs. Let's do it once more, possibly leveraging someone else's work and make it part of the OS.

  • BHTMLView - include JavaScript? External players? Use some existing framework?
  • How about an Outlook bar? Or a grid widget? Many new controls possible, look at other OSs. Graphs and charts
  • How about a BImageFilePanel? One that queries the device system for image yielding devices and has neat features like thumbnails, etc? Or a BSoundFilePanel that lets you play snippets before loading the whole file? Still-Image Acquisition & Moving-Image Acquisition
  • RAD / easy graphical GUI-creation toolkit
  • Color Management
  • Multiple monitor support
  • LayoutManager (already in the works for R1)
  • workspace sharing via network
  • investigate ZUI concepts
    • access embedded data (e.g.: email attachments) in-place
    • spatial data organization
  • look at Morphic/Tweak, Chalk (Slate's CLIM+Morphic combination)
  • replicant may run as separate process?
  • OpenBinder
  • scalable UI
  • gamma correction?

Localisation

This would be fantastic it would allow easy language localization of any part of OBOS (OS included) to a specific language and it would allow for users to have several languages available in is system in just one installation.

All higher layers of system should use some kind of localisation. This covers:

  • Language translation files for applications
  • Time and Date writing order/conventions
  • Currencies
  • Number spacing
  • Keyboards
  • Fonts ( BeOS default fonts are lacking some Latin European glyphs )
  • API/GUI should be able to fit different font sizes and string lengths (Example: Chinese has very big chars)
  • system–wide Unicode/UTF-8 is a must

Localization - this is probably the single most requested feature. And one of the biggest. Because this ties into so many other things. At minimum, we need to add currency, calendar, number widgets, phone number, address that tie in to the locale. Plus automatic translation support (i.e. translate phrases into current locale's language), resizeable, font independent widgets, right to left and top to bottom text, etc. There is a *huge* amount of work in doing this right. Layout management, too, so that resized widgets can flow properly.

Note: Axel Dörfler is already working on this in the OpenTracker repos.

Kernel & Drivers

  • ability to move processes from one machine to another (load balancing)
  • Anyway, a good thing to add is device feedback. This way drivers would be able to implement force-feedback for mice, for example.
  • A method for drivers to publish functionality in a standard way. It could be only metadata. It would allow querying to discover if certain functionality exists in the driver and/or the hardware
  • Power Management and other "special" laptop support
  • Bluetooth
  • FireWire
  • CardBus/PC Card
  • PCI Express
  • 64-bit processors
  • Debugging via the kernel
  • RAID (hardware and software)
  • Hardware–accelerated OpenGL
  • EFI (UEFI 2.1)
  • Enhanced SpeedStep
  • WiFi (2200BG, 2915ABG, 3945ABG, PRISM?, USB adapters, ...)
  • Firewire
  • Intel graphics drivers
  • more file systems (NTFS r/w, UDF2.6+attrs r/w, ZFS, XFS?, EXT2/3FS?, ReiserFS?)
  • FS-independent indexing service (e.g.: Beagle), but might use FS index (if available) for faster queries
  • userland FS API
    • LDAP address book
    • IMAP
    • IMAP address book + calendar + notes [plug-in based backend]
    • WebDAV?
    • FTP
    • P2P with queries [BeShare?]
  • transactional VFS (see Windows Vista)
  • versioning VFS
  • FS ACLs
  • extend node monitoring to monitor all VFS calls
    • not only specific directories
    • allow for filters that can intercept and deny access (e.g.: virus scanners)

Network

  • ZeroConf / Rendezvous / uPnP
    • with support for add-ons: e.g., instant messengers could use ZeroConf to expert services to your friends
  • event-driven API (new device, configuration changed, (dis-)connected, etc.)
  • mobility-oriented
    • access important functions and profiles via Deskbar replicant
    • auto-recognition of profiles
    • update default printer and PPP connection
    • update timezone?
  • IPv6
  • WiFi with full encryption support (WEP, WPA, WPA2)
  • RADIUS client authentication
  • anonymizer modules (Tor, DNS translation, etc.)
  • NDIS wrapper
  • networked file system

BeMail

  • show all drafts in a list on the left
  • closing will auto-save your email. no need to save your work
  • unlimited undo history is stored for all drafts, so you can undo something even after having closed BeMail

Tracker

  • Not only does it offer a more efficient space, it enhances the usefulness of the OS by offering a place to stash information vital to the user. Some examples of replicants that could be of use would be a pulse like CPU histogram, a virtual workspace manager, a clock and calendar, controller for audio players, applications/script/folder shortcuts and a drive space monitor, to name a few. I'm sure others can come up with more. It would be left up to the user to decide what they want to display as a deskbar replicant, in what order they want them displayed and how they want it displayed.
  • what if "My Computer" opened into a mime type directory. You could either look at a type's subtypes OR look at the files with that mime type.
  • In the Tracker with an icon(or icons) highlighted, you decide to copy them to another directory. You simply right click, move the cursor over Copy To and you then proceed to find the directory you wish to copy them to. Now you find a few more files(we will use mp3s as an example) that you wish to copy to the same directory. You simply right click, move the cursor down to Copy To, but this time when the next menu forms their is an option at the top that says Most Recent or Recent. Moving to the right on this item shows you the last 5 or 10 directories that you have copied to. This functionality would be available from the Create Link, Copy To, and Move To pop–up menus.
  • integrate xcv ([1])
  • This could be implemented like this: when the appropriate file is highlighted, make Tracker extend its viewable area, like a drawer, and this drawer should work like R4's Container; attach a new replicant that can handle this file type. BeMail could be made a replicant, NetPositive already is (could be the handler for graphic files), SoundPlay also...
  • Folder backgrounds are stored as an attribute of the folder. Why can't we preview images by clicking once on them and have Tracker send them into the open folder's background attribute? For that matter, any type of data/media could be handled the same way. Video, audio - all that stuff. We can even have tracker do cool things like make a split pane to preview emails and text documents (any kind of document that we have a "tool" reader for - Gobe, Word, Abiword, etc.).
  • What about allowing "rules" for file management on the desktop, i.e. when files are dropped there.
  • rework queries and UI (categorization, time-slider/scroll-to field)

BFS

I think it would be useful to have attributes with both a name and an index: you could get the 6th attribute named "foo", for instance. This is useful because it lets you associate more than one value with a single attribute in a system-defined way. If we had an installer that tracked what libs an app depended on, it could place those in attributes and query for them, without worrying about separating the lib names with some kind of token. MP3s could have multiple authors. We could also give translators an attribute for what they translate, which would make this obvious to the user, *and* obviate the roster: the system would know where it was going. Currently, we have only one value for attributes which is very annoying with a Contact's email addresses: we use tricks like "Person:Email"="first@mail.com, second@othermail.com". This has to be changed. Think of BMessage: "Person.Email" gets an array of values: "Person.Email"[0] = first@mail.com "Person.Email"[1] = second@mail.com How this is handled with indices: the "Person.Email" index may simply contain multiple entries pointing to the same file.

  • Full text indexing.
  • versioning
  • maybe replace BFS with a DB (DR8, but much better)

Components

The micro solution consists of reverting to the computing roots of the D+F concept (data and functions, no programs). That is, the killer app for GE is that there is NO app. Your system consists of functions which the user invokes in which ever order they choose, and vendors ONLY provide functions. They no longer provide programs. The entire User Interface has to be changed to allow for an entire different concept of work flow. Let me repeat that one more time - a new work flow requires a change in the user interface (think fundamental change like the change from CLI to WIMP).

I connect the Cron component to the MediaPlayer object and boom - alarm clock. This is what OO was supposed to bring to coders. We are talking about bringing it to end users. Of course, just like, say, themes, there will be builders and there will be users. But what we are really talking about is making coding message based and more modularised. The idea of wrapping complex structures in one binary file & using special dev/apps tools to poke inside seems to be giving way to keeping 1 simple type in each file, & letting a folder keep it all together. Advantage is any suitable app can edit specific components. Apple used to use resource forks with ResEdit, now they want all to use the hidden folder approach. Much much easier on tool developers since you reuse what is already out there.

[ Note that the enlightenment foundation libraries ( http://www.enlightenment.org ) goes some way toward making this possible. Combinations of Embryo, Eet and Edje allows this level of customization through "themes" for a single application. ]

Lets make it cooler, you get your components, link them up Cortex style and save them as new processes. Imagine browsing through your Video directory and previewing the video using the folder's background as a screen. The icons maybe will become slightly transparent so that you can see the video a little clearer, but not much because it is - after all - just a preview to see if it's the right document.

Input Kit

  • fix the InputServerMethod issues.
  • I also have been thinking of moving Joysticks to the input_server.
  • allow users to determine the order in which input is passed to the InputServerFilters.
  • allow for system wide key bindings
  • MIME/Roster
  • File types are more human-readable: Document, Image, Video, etc. In our local database we store the MIME translations for those types. Multiple-inheritance is supported, too (Ogg would inherit from audio/ and video/, for example). Instead of specifying attributes for each format individually (MP3 has its own attribute set) the attributes are inherited from the supertype (Audio). Internally, the file types are stored as MIME. This allows for better OS-interoperability, backwards-compatibility, and more flexibility (we can change the inheritance structure of the whole type database and it will continue to work). But there is a problem with this model: global queries (Audio/*) would have to look for multiple MIME-types (application/ogg, audio/*, etc.). Nevertheless, it should be a step forward, usability-wise.
  • BClipBoard - ability to have multiple items on the clipboard

Translation Kit

  • meta-data (also for file attributes)
  • 2D/3D vector graphics
  • documents (OpenDocument-based API?)
  • spreadsheets
  • databases?
  • viewers + editors API (like replicants)

Support Kit

  • Lots of new classes for here, too. There are numbers of useful little helper classes that we could all use... How about a pool allocator, as an example.

Other

  • User preferences USB stick (flash storage) - on boot/disk insertion, check to see if there is a removable volume mounted that has a home directory on it. If so, boot using this as home; allows visiting users to bring their preferences/apps/data with them. Basically a Haiku install minus the system on a flash drive/CD/whatever.
  • bundles
  • read-only base system (separate partition), read-write overlay system for additional apps, and mobile user profiles (see BSD-HALO)
  • collaboration services (multiple persons working on one document over the network )
  • download_server + API (does this make sense, at all???)
  • input profiles?? (mouse, keyboard, joystick?)
  • energy profiles

Some vague ideas...

Posted Wed, 2002-10-16 05:00 by admin

Late at night, beating my brains for yet another newsletter article, my eyes were drawn to a notebook nearby my desk. This notebook contains my ideas that I brainstorm for future versions of OBOS. One of the complaints that people have is that R1 as we have defined it has no "future". It doesn't do anything beyond recreate what Be did and that we should aim higher for our first release. Interestingly enough, there is another, equal sized crowd of people who say that we are trying to do the impossible. In either case, R1 will be what it will be.

R2 and beyond are wide open, though. The following are some bullet items, some thoughts and ideas. Nothing solid, nothing developed, nothing thought through all the way, and certainly nothing promised. But some ideas, none the less...

XML - possibly methods for BMessage to transform to and from XML, possibly a whole different kit

Encryption - a plug in architecture for encryption/decryption. Probably public/private key. With a key manager of some sort, so that it is easy for users. Also with a tie-in to the Mail Kit of some sort so that mail programs can quickly and easily encrypt and decrypt messages. Also a cache of public keys with methods to refresh them (via Networking Kit)

Additions to BBitmap - this class is really in need of a lot more "stuff". Think LeadTools for Windows - the ability to choose some area of the bitmap and apply transforms (plug ins). This has been done a dozen times for a dozen different art programs. Let's do it once more, possibly leveraging someone else's work and make it part of the OS.

In a similar vein, how about a BSound class that adds effects? Mute, slide, reverb, echo, etc. All, again, as plug ins.

Vastly improved printing is needed. Color management is huge, now, with digital photography. Additionally, more functionality is needed. Watermarks, more margin control, etc. All of those "extras" that you have on Windows and use once a year.

BHTMLView - I am not sure how this one should be done, but it is just obvious to everyone that we need one.

Localization - this is probably the single most requested feature. And one of the biggest. Because this ties into so many other things. At minimum, we need to add currency, calendar and number widgets that tie in to the locale. Plus automatic translation support (i.e. translate phrases into current locale's language), resizeable, font independent widgets, right to left and top to bottom text, etc. There is a *huge* amount of work in doing this right.

Game Kit - this kit needs a massive overhaul. Be never really took it seriously, but I do. Sprites, Backgrounds, collision handling, parallax, 3d, scrolling, tiling, AI, controllers (joysticks, etc) and more. This kit could almost be a career for someone.

IM Kit - I have heard rumours that this is being worked on. Possibly leverage that into our work. This kit could be useful in a dozen different apps. Tech support in your office suite? Inter-player chatting in games? More and more, we are all connected...

Device Kit - if there is any less cared for kit out there, I don't know what it is. Only BJoystick (which belongs in Input Kit) and BSerialPort remain. But why does serial port deserve a class but not BParallel? Or BAudioCD? Or BVideoCD? Or Scanners, Cameras, PDAs, etc? Every "thing" that you plug into your BeOS machine should have a class to access it. Banish ioctl()'s forever!

Tracker - A lot of code clean up to happen here. After that, I would like to experiment with different, alternate Trackers. The desktop metaphor doesn't work for everyone. I don't think that anything works for everyone. Let's make a couple or more different Trackers and see if they suit someone's needs.

BClipBoard - ability to have multiple items on the clipboard

Interface Kit - there are dozens of widgets missing from here. Not to mention all of the stuff we mentioned for internationalization. How about an Outlook bar? Or a grid widget? Lots of honest work to be had, here.

Storage Kit - I think that this is a little hard to use. Lots of times, I have found myself taking the long way around on some simple things. Maybe some better methods...

Support Kit - Lots of new classes for here, too. There are numbers of useful little helper classes that we could all use... How about a pool allocator, as an example.

DataBase Kit - access for SQL databases will be a large sticking point to getting on the corporate desktop. The sooner the better.

Translation Kit - Good kit, as far as it goes. How about 3D objects? Or vectors (structured drawing)? HTML read/write? Tons of good work to be done here, too.

A CD Writer application is a critical piece that we lack. And a scanning app. Simple stuff that come with other OS's.

Power Management and other "special" laptop support

A dock - every OS should have one of these.

As you can see, there are a ton of ideas. And I know that every one of you has some, too. These are just mine. R1 is a stepping stone. A place to start. Not a place to end up. I certainly don't intend to rest on my laurels when R1 is done. I intend to step it up another notch and build what Be didn't have time to finish.


Syndicate content