Pardon, I didn't follow the progress of envy24control. Did you finish
the recently development and if so, where can we/I get the latest source
code?
Cheers!
Ralf
Hi everybody,
Fallowing up the long discussion i'm trying to sort of give the
information you all seem to be missing.
there was a meantion of this, but not too many of you have paid any
attention:
here you can find an article about the current status of the protocol mess:
http://prosoundnewseurope.com/pdf/PSNLive/PSNLive_2009.pdf (page 28)
obviously eas50 is good to go, but Ethernet AVB is right thing really.
the only thing that it's still work in progress, but many of the
proprietary vendors, which already have their own networking solution
(like Harman with HiQ-net, the one i can name of top of my head)
are involved in AVB stadard deveelopment.
The idea of AVB is to bypass the IP layer, which is right thing really.
you don't need to assign IPs to your audio nodes, really!
in avb you'd just have to select channels that nodes whant to listen to.
there is a fair bit of documentation on the ietf.org AVB group's page.
but XMOS is looking to be the best point of refference:
http://www.xmos.com/news/15-jun-2009/xmos-simplifies-ethernet-avb-implement…
is think we should forget everything else and crack on with the XS1 AVB
implementation!
their XS1 chips seem to be really great,
their are basically every innovative and open-source minded.
the official toolchain is LLVM-GCC based.
you can use C, C++ or their own XC.
XC is basically C with some stuff omited (like goto and floats)
and XMOS IO stuff added, don't just say WTF, look at it first!
you should also watch the videos here:
http://www.xmoslinkers.org/conference-online-wf
especialy the two about the "XMOS Architecture" and the AVB
presentation.
some dev-kits are quite expencive, but that's due to low-volume really
;)
there is alos a nice USB Audio kit!
plus there is alittle board that is cheap and has two RJ45's on it
already :)
I'm myself studying the XC book at the moment. And geting familiar with
the tool set :)~~
looks very exciting, cause these are the invovative chips!
ok, may be an FPU is really missing on XCore, but how many DSPs have
it anyway? well quite a few, but there was no FPU on dsps for ages! :))
also XC or C/C++ are so much more obvious then the bloody "menthal american military engeneers non-sense" called HDL-whatever!
Cheers Everyone,
Hope you will appreciate my excitment :)~ (l0l)
--
ilya .d
It's TYOQA (The Year Of Qtractor Automation:) what else?
But wait, there's three months to go yet. Meanwhile, the foundations
have already been laid and one can now tell that a rocky milestone is
ready to get bumped. Ouch!
Qtractor 0.4.7 (furious desertrix) is out!
Release highlights:
- MIDI learn/controller mapping for all plugin parameters (NEW)
- Extended Clip fade-in/out WYSIWYG curves (NEW)
- MIDI resolution overflow (FIX)
- MIDI tempo standard base on quarter-note (FIX)
- Extended MIDI controller mapping for mixer/tracks (NEW)
- Audio metronome gain control (NEW)
- Mute/solo tracks while looping (FIX)
- MIDI Clock support (NEW)
- Audio clip import while looping (FIX)
- MIDI track bank-select/program-change transparency (FIX)
- VeSTige headers included for native VST plugin support (NEW)
- JACK transport sync support (FIX)
- Clip tempo-adjust tool (NEW)
- Audio tracks auto-monitoring (FIX)
- Transport back/forward stops on loop points (NEW)
- MIDI tracks redundant mute/solo (FIX)
See also:
http://www.rncbc.org/drupal/node/235
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
- source tarball:
http://downloads.sourceforge.net/qtractor/qtractor-0.4.7.tar.gz
- source package (openSUSE 11.3):
http://downloads.sourceforge.net/qtractor/qtractor-0.4.7-1.rncbc.suse113.sr…
- binary packages (openSUSE 11.3):
http://downloads.sourceforge.net/qtractor/qtractor-0.4.7-1.rncbc.suse113.i5…http://downloads.sourceforge.net/qtractor/qtractor-0.4.7-1.rncbc.suse113.x8…
- user manual (nevermind outdated):
http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf
Weblog (upstream support):
http://www.rncbc.org
License:
Qtractor is free, open-source software, distributed under the terms of
the GNU General Public License (GPL) version 2 or later.
Change-log:
- While moving multi-selected MIDI events around the clip editor (aka
piano-roll), with help of keyboard arrow keys, that is, was not clear
which one was the so-called "anchor" event, the one which positioning
gets honored for snap-to-beat business. Not anymore: the anchor event
now defaults to the earliest in time or the one the user's last
point(-click)ed.
- MIDI control observer pattern implementation has sneaked in, making it
ready for the so-called and long-awaited "MIDI Learn" feature and
arbitrary MIDI controller assignment, for plugin parameters in particular.
- MMC DEFERRED PLAY doesn't cause transport state to stop if currently
rolling (mitigating bug #3067264).
- Audio clip merge processing might have been skipping a few initial
frame blocks, now fixed.
- Clip selection and plugin parameter hash optimization.
- Anti-glitch audio clip macro fade-in/out fixed again.
- New clip fade-in/out slopes (curves) are introduced, partially adapted
and refactored from those easing equations of Robert Penner's fame.
- Clip fade-in/out non-linear slopes are now shown as actual WYSIWYG curves.
- Escape key now closes generic plugin widgets as ever found usual
elsewhere.
- Picking nits: unselect current track when clicking on any gray empty
area, also accessible from a new menu item: Track/Navigate/None.
- A nasty and deadly MIDI resolution overflow has been finally fixed,
allowing for long MIDI sequences (1h+) to load correctly on 32bit
machines from now on (was perfectly fine on 64bit though).
- MIDI editor selection hash optimization in face of reasonably huge
event sequences.
- MIDI controller mapping finally refactored to support some other MIDI
event types than just CC (0xBn) ones.
- Nitpicking fix: corrected main track-list (left pane) display when no
track is currently selected.
- libX11 is now being added explicitly to the build link phase, as seen
necessary on some bleeding-edge distros eg. Fedora 13, Debian 6. (fixing
bug #3050944).
- New audio metronome bar and beat sample gain options.
- Progressively, the observer pattern is being finally introduced,
targeting all potentially automation controls and widgets as plain
ground-zero for the (ultra-)long overdue automation feature.
- MIDI controller mapping of still non-existing tracks were being
implicitly assigned to the last, highly numbered, existing track. Now fixed.
- Moving from old deprecated Qt3'ish custom event post handling into
regular asynchronous signal/slot strategy.
- Muting/soloing tracks while playback is looping was leaving current
audio clip out-of-sync whenever that same track is later un-muted on any
other preceding clip. Now hopefully fixed.
- MIDI Clock support makes its first appearance.
- All tempo (BPM) calculations are now compliant to the MIDI
conventional equivalence between beat and quarter note (1/4, crotchet)
as common standard time division.
- Automatic audio time-stretch option is not enabled by default anymore.
- Standard warning Apply button is now only shown when dismissing dialog
changes are actually valid.
- Make sure non-dedicated metronome and player buses are properly reset
and reopen when changing regular audio buses (hopefully fixing bug item
#3021645 - Crash after changing audio bus).
- Hopefully, an outrageously old bug got squashed away, which was
causing random impromptu crashes, most often when importing audio clips
while looping and play-head is any near the loop end point.
- General standard dialog buttons layout is now in place.
- Fixed main track view off-limits play-head positioning.
- Main tool-bar Time and Tempo spin-boxes, may now have their colors
correct, as for most non-Qt based theme engines (ie. Gnome). Green text
on black background has been and still is the the intended aspect design ;)
- MIDI file import and internal sequence representation has been changed
to be inclusive on all bank-select (CC#0,32) and program-change events
which were previously discarded while honoring MIDI track properties.
Interleaved SysEx events are now also preserved on their original
sequence positions instead of squashing a duplicate into the MIDI bus
SysEx setup.
- Attempt to include the VeSTige header by default, as for minimal VST
plugin support.
- JACK transport support has been slightly rewritten, in fact the sync
callback is now in effect for repositioning.
- The MIDI clip editor (piano roll) widget won't be flagged as a tool
window anymore.
- A tempo adjustment tool is making inroads from the menu, as
Edit/Clip/Tempo... (factory shortcut: F7).
- Audio tracks auto-monitoring is now effective on playback.
- Make sure to ask whether a dirty MIDI clip should be saved, upon
resizing or stretching its edges (fixes bug #3017723).
- Backward and Forward transport commands are now taking additional
stops on loop points.
- Attempt to optimize track solo/mute redundant transactions, in special
regard to MIDI track events which were being duplicated on soloing and
temporarily muted on unsoloing.
Cheers && Enjoy (be happy!)
--
rncbc aka Rui Nuno capela
rncbc(a)rncbc.org
http://www.youtube.com/watch?v=AoAOx97G8ewhttp://www.gizmag.com/roger-linn-linnstrument-digital-music-interface/15155/
........
Sadly, that's unlikely to happen anytime soon - because the TouchCo
multitouch pad that Linn used in the production of his prototype has
been withdrawn from production. Apparently Amazon bought up the
technology earlier this year (
http://www.nytimes.com/2010/02/04/technology/04amazon.html?_r=1 ) with
a view to using it in the Kindle eBook reader, but has completely
shelved it and shut down the TouchCo operation, presumably due to the
ongoing Intellectual Property chest-beating, suing and counter-suing
going on in the multitouch arena right now.
So the TouchCo website has nothing but a sad placeholder to offer (
http://touchco.com/ ), and Linn has nothing but his pre-production
prototype to work with, ruling out the possibility of a LinnStrument
hitting the market in the immediate future.
........
Could the meego touch API support the features needed by the
instrument used in the above Youtube Video of Roger Linn? Some of the
swipes and other gestures demonstrated in the video are available in
http://apidocs.meego.com/mtf/gestures.html but an important one isn't:
multitouch pressure sensitivity that is equivalent to "polyphonic
aftertouch" on a MIDI keyboard -- allowing analog pressure readings to
be taken continuously and simultaneously per touch.
Is there interest in making such devices part of the "use case" for meego touch?
And are there any such displays&touchsensors available for use with
Meego capable hardware such as the beagleboard?
I imagine one could extrapolate touch pressure by looking at how much
area each touch consumes, dynamically -- (assuming a normal human
finger whose tip would deform and cover more surface area with
application of more pressure).
Niels
http://nielsmayer.com
Hey guys!
I have two questions.
1. How does Sound Stretch work? It is incredible the way it can produce a
tone which has no noticeable vibrations, just a wall of sound. How is that
accomplished, in layman terms if possible :)
2. Can this program be jackified and is that a lot of work?
--
Louigi Verona
http://www.louigiverona.ru/
if there was a standard that described the expected behavior of commonly
used
(or just useful) knob control methods, perhaps in the form of a short draft
specification on freedesktop.org, would people (ie developers) use it?
expectations and requirements clearly differ so we would probably need to
gather together and discuss those in use with a mind to removing or
combining
similar methods, explicitly naming them and defining their behavior in the
abstract. if we required that applications implement a set few methods as
configurable options (as a minimum) in order to comply then we might
eventually
see the back of the unpredictable mess we have now. it wouldn't matter
how they
are configured, be it gconf, dotfile, command line, prefs dialog, env
variable..
as long as it could be done.
worth thinking about or is it just too niche? are the actual real world
applications too varied and specific to make it useful?
for example it would certainly be nice to crack open a library config
or application prefs window and assign VLMC (vertical linear motion
control*)
to the left mouse button and RMC (radial motion control*)
to shift + left mouse button, and have those conform to the expected
standards.
or even just to set KNOB_CONTROL_METHOD=RMC in your global environment
and have all the adherent applications just do what you expect.
it seems to me that standards (of the mutually agreed rather than officially
sanctioned variety, since the latter is impractical) provide the best means
to bring about common behavior in sovereign systems. naturally it would be
completely platform independent.
just having named control methods with explicitly defined behavior may
help matters
too.
cheers,
pete.
*crappy names i'm sure, but you get the idea.
