Hello everyone, I apologize for using an online translator, but for clarity will attach also the text in the original language for those who understand Italian.
just use reaper, has been attracted by two main technical prescriptions.
one is the folder track, and the second is the engine audio processing 64-bit floating.
the folder track is an advanced group management, and allows you to apply effects to the “master track of the group” and speeds up a lot the management of the group and of the tracks, plus it’s a good implementation of workflow enhancing the system send and buses.
the engine does not beat 64 floating point instead of a clean sound and a definition of the details very enviable.
another feature that I think is interesting and little support for the JS in java programming language dedicated to making scripth from uasare as a plugin, would expand greatly the amount of plugins available.
I’m saying blasphemies?
ps. I read about the possibility of an implementation of a resynthesis engine, is not it?
italian language
salve a tutti, mi scuso per l’uso di un traduttore online, ma per chiarezza allegherò anche il testo in lingua originale per chi capisce l’italiano.
da poco uso reaper, è sono stato attratto da due caratterstiche principalmente.
uno sono le folder track, e la seconda è il motore di elaborazione audio a 64 bit non floating.
le folder track è un sistema di gestione dei gruppi all’avanguardia, e permette di applicare gli effetti alla" traccia master del gruppo" e velocizza di molto la gestione dei gruppo e delle traccie, in più è una ottima implementazione del workflow potenziando il sistema send e bus.
il motore a 64 beat non floating point invece da una pulizia al suono e una definizione dei dettagli molto invidiabile.
un altra caratteristica che secondo me pò essere interessante e il supporto al JS un linguaggio di programmazione in java dedicato a fare scripth da uasare come plugin, allargherebbe di molto la quantità di plug a disposizione.
sto dicendo blasfemie?
ps. ho letto della possibilità di un implementazione di un motore di resintesi, è vero?
64 bit processing is a completely bogus sales/marketing tactic. No (let me repeat that, no) double blind test has ever shown any difference to audio processing with 64 bits over 32. Synthesis is slightly different, but plugins are free to do whatever they want internally, and simply convert 32 bit for input and output. The same is true of any other processing. Certainly nothing that Ardour itself does to the signal would benefit from 64 bit processing. If you think that Reaper (or any other system) "sounds better" because of 64 bits, you need to setup a properly structured double blind test. I almost guarantee that your belief will be gone by the end of the test.
folder tracks were partially implemented but it did not go well. Maybe it will happen again, maybe it won't. A number of features of "folder tracks" can be handled using ardour "groups" facility, and for a number of things, the working style will be much more familiar to anyone with experience of a hardware console (which is not necessarily good or bad). Subgrouping (routing all tracks/busses in a group to their own bus) allows for per-group FX, easier I/O management, etc. etc).
we are not going to support scripting languages like javascript (because they are horrible). languages like lua or python or ruby are a possibility. BUT ... you cannot write plugins in a scripting language unless your target is a toy. Also, the problem with plugins is not the number that are available but WHICH plugins are available. Javascript (or Lua) does not solve this in any way. Scripting languages within Ardour, if they ever happen, will likely target MIDI data transformation and possibly audio editing.
i think you possibly misunderstand how open source development takes place. Ardour has been around for more than a decade. Features like the ones you are describing are all big, substantial pieces of work (actually, 64 bit processing is a relatively trivial change). They don't happen when 1 or even a dozen users has the idea and asks for it to be implemented. They happen when either (a) a sufficiently skilled and motivated developer finds the time to implement it or (b) someone pays a skilled developer to implement it. If you want to get developers motivated, the ardour-dev mailing list is a much better idea than this web forum, which typically is populated by users. Users are the most important, except that they don't do development (typically).
The list of things that I/we plan to work on after the release of 3.0 can be found here, as well as some items from the bug/issue tracker (http://tracker.ardour.org).
Very true, but, just for fun - and an odd definition of fun perhaps - I recently managed to port a plugin entirely to HTML5 / javascript (using the Web Audio API available in google chrome) and to my great surprise it actually worked… although typically it takes about 50% of the CPU to run one instance - but it was interesting to be able to embed the plugin (with GUI) in a web page and put various media sources through it…
(This is cheating a little too since google seem to have done some very clever things in chrome to enable javascript to be very efficiently JIT compiled or similar and run surprisingly fast)
- I recently managed to port a plugin entirely to HTML5 / javascript (using the Web Audio API available in google chrome) and to my great surprise it actually worked… although typically it takes about 50% of the CPU to run one instance - but it was interesting to be able to embed the plugin (with GUI) in a web page and put various media sources through it…