Gabriel M. Beddingfield wrote:
>
> All:
>
> Attached is the promised feature list. If you'd like to add stuff...
> let me know, BUT:
>
> Now that we have all our pet features out of our system, let's hammer
> out a _vision_ for what we want in the future. (...as Alexandre wisely
> advised.)
>
> A vision statement should be 1 to 5 sentances on what we want Hydrogen
> to "look like" in the future. (I.e. what purpose will Hydrogen serve to
> its users?)
>
> FWIW, right now there's primarily 2 visions being thrown around:
>
> * A drum machine program (full of bells and whistles)
> [Sim. to Rezound]
>
> * A "live" sequencer/sampler/synth with a streamlined workflow
> [Sim. to Live]
>
> So, ask yourself: What do *you* want to see? What have users told you
> that they want to see?
Hi Gabriel,
My vision for Hydrogen is very simple, and it does most of what I need
right now: I want to be able to drive Hydrogen from a set of electronic
triggers, and I want to model the sounds that come from an acoustic kit
as accurately as possible.
I suggest the following feature, and please forgive me if it's already
possible to do this, I've only just started working with Hydrogen.
I think that the sample that's played for any given MIDI note is the
same regardless of velocity, whereas an acoustic drum will make a
slightly different sound, not just more or less volume, depending on how
hard the drummer strikes it. I'd like to see the ability to set the
sample for a note depending on the velocity of the note.
The XML describing a kit could contain a few separate tags for the
filename such as:
<instrument>
<id>0</id>
<filename>kick_Dry_b.flac</filename>
<filename velocity="0-45">kick_Dry_b_0.flac</filename>
<filename velocity="79-127">kick_Dry_b_3.flac</filename>
<name>Kick</name>
<volume>1.000000</volume>
<isMuted>false</isMuted>
<pan_L>1.000000</pan_L>
<pan_R>1.000000</pan_R>
<exclude />
</instrument>
The code could then select the proper sample for a given velocity,
falling back to the <filename> tag without a velocity attribute if it
receives a note with a velocity for which it has no specific sample.
That would be backward compatible with existing kits. Depending on how
realistic the kit developer wants to get, there could be more or fewer
samples for each instrument. One might also use this functionality to
implement audio output that could not exist in the physical world, which
could be fun, say, having a drum that shatters every time it's played
with a velocity of 127, or as a practice aid tells you to play louder
below a certain velocity, etc.
Dave
> Peace,
> Gabriel
>
> ------------------------------------------------------------------------
>
>
> Hydrogen Future
>
>
> Visions
>
> A monolithic, "live" DAW
> A live performance sequencer.
> A composition environment with a real sampler.
> A complete system for music composition, creation, and performance.
> Ableton Live clone
> A virtual drum machine
>
>
> Features
>
> Merge all the features from Wolke's branch
> Merge and complete the transport redesign branch (2)
> Asynchronous playback of multiple sequences.
> Instant song loading (internal) -- or at least some way to have a
> library of songs or sounds that will load with near-zero latency.
> Full MIDI bindings for triggering samples, songs, etc.
> Full automation/control for external apps/devices to control hydrogen
> (MIDI, OSC, etc.)
> Per-song volume control
> Tempo changes as part of the sequence.
> Able to control external applications (MIDI, etc.)
> Instant multitrack record via JACK/Ardour/Renoise/Etc.
> Full session state via LASH
> Control external apps via Hydrogen bindings/sequence.
> Spin off the library with the audio portion as a standalone library.
> Drum-set "roles" or General MIDI features so that patterns can
> interchange drum sets without a lot of hassle.
> Support for misc. file formats (Guitar Pro, Simple Midi File, MusicXML,
> etc.)
> Preload several sample patterns with different styles and meters
> Copy/paste patterns, portions, etc.
> Undo
> Nondestructive editing
> A sampler/sythensizer back-end that supports an object-based paradigm.
> Instead of triggering samples, you can trigger any of (a) a sample, (b)
> a short sequence, (c) a song-like aggregation of the above, (d) a
> control command (MIDI/OSC/python/etc). Sequences that are being
> triggered may be done asynchronously (beats don't line up), beat-synced
> (beats line up, but not bars), or synchronously (bars and beats line up,
> pattern will start mid-bar).
> Audio loops with time stretch (both beat slicing and time stretch)
> One scree, uncluttered interface. Make sure that it works with Netbooks
> (like the EEE PC).
> JACK only. Reduce the number of drivers that we support and focus on
> what we do best. In redesigning the backend, I've noticed that I'm
> having to RE-implement JACK in order to maintain compatability with all
> our audio drivers. This is a duplicate effort.
> JACK MIDI
> MIDI Out
> Real-time tempo sync with down-beat snapping. (Like InConcert *almost*
> does)
> Client/server model. Able to run "headless." Able to control H2
> instances on hosts that are distributed on a network.
> Real-time looping with overdub (even if we're just being a front-end for
> sooperlooper).
> Scripting engine
> Ability to record audio and manipulate it in real-time.
> Ability to record MIDI and manipulate it in real-time.
> Continued support for effects.
> Hydrogen available as a plugin to other apps.
> Support different sample formats.
> OSC support.
> monome.org support
> Better access to metadata for samples while editing an instrument. E.g.
> ability to right click and then "open file location" or something like
> that.
> Some manner of cue points or bookmarks within a song or sequence.
> With cue points... allow them to be triggered externally.
> Simple sample eding. For example, trim points for each sample so you can
> trim a sample in hydrogen without making a new sample file. It would be
> great if it used points and lines so you could edit any portion of the
> sample. not just the front and back. This could also be implemented as
> "automation", as ardour does it.
> Remove the 32-channel limitation
> Pitch shifter and time stretcher capable of fine tuning to 100th steps.
> Restore from crash.
> Automation (ardour style) on individual squares (bars) in the song
> editor. This would allow pans, fades, effect, etc. to be dynamically
> assigned to the song.
> Color shading of the grid in song editor (rainbow by default with the
> option to assign custom colors to a row). On large compositions, it's
> hard to know which patter your adding/subtracting.
> Windows build
> A kinder, gentler build system.
> Command-line version of hydrogen
> Have two front-ends that are run-time switchable.
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Hydrogen-devel mailing list
> Hydrogen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Hydrogen-devel mailing list
Hydrogen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
