Re: [LAD] [ot] capitalising words in a shell-script
Well, that dream was not mine but Dennis Ritchie's and Ken Thompson's... - Original Message - From: Jens M Andreasen [EMAIL PROTECTED] To: victor [EMAIL PROTECTED] Cc: linux-audio-dev@lists.linuxaudio.org Sent: Saturday, September 27, 2008 1:31 AM Subject: Re: [LAD] [ot] capitalising words in a shell-script On Sat, 2008-09-27 at 00:44 +0100, victor wrote: Gone is the dream of UNIX. Long it live. I dunno what your dream is? ... But my nightmare is the day when procesors gets so powerful so that the new kids on the block decides to rewrite the (Linux)kernel in javascript! Solutions of simple problems, demanding several complex packages to be piped into one each other, does not take my fancy. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ot] capitalising words in a shell-script
2008/9/27 Jens M Andreasen [EMAIL PROTECTED]: ... But my nightmare is the day when procesors gets so powerful so that the new kids on the block decides to rewrite the (Linux)kernel in javascript! Still in planning stage, but maybe not that far away: http://sourceforge.net/projects/cleese/ Solutions of simple problems, demanding several complex packages to be piped into one each other, does not take my fancy. Well... some unix gurus would claim here that unix piped *simple command tools* i.o. to accomplish *complex tasks*... depends on the vew ;-)) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] multiple ICE1712 sound cards (as one huge soundcard)
Thanks Julien for the quick reply! I just realized that ALSA only detects one of the two envy cards. For example aplay -l just shows this: List of PLAYBACK Hardware Devices card 0: DSP24 [Hoontech SoundTrack Audio DSP24], device 0: ICE1712 multi [ICE1712 multi] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: DSP24 [Hoontech SoundTrack Audio DSP24], device 1: ICE1712 consumer [ICE1712 consumer] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: DSP24 [Hoontech SoundTrack Audio DSP24], device 2: ICE1712 consumer (DS) [ICE1712 consumer (DS)] Subdevices: 6/6 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Subdevice #3: subdevice #3 Subdevice #4: subdevice #4 Subdevice #5: subdevice #5 Which equals output when only one card is plugged in. But lspci shows both cards: 02:08.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24] PCI Multi-Channel I/O Controller (rev 02) 02:09.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24] PCI Multi-Channel I/O Controller (rev 02) Do I probably need a more recent ALSA version or a specific patch or something? Currently I'm using ALSA 1.0.12 drivers. CU Christian Es geschah am Wednesday 24 September 2008 als Julien Claassen schrieb: Christian! Did you try ALSA only. It looks like an alsa problem. So tests with aplay or something might be helpful. You know, that aplay can be launched with a verbosity switch? I believe you can put -vv (or VV, not sure) there to get even more output. With aplay you should playback a file with enough channels, so ALSA doesn't get confused with channel-counts in audiofile and PCM device. That might only be a first pointer, but hopefully of some help. Kindest regards Julien Music was my first love and it will be my last (John Miles) FIND MY WEB-PROJECT AT: http://ltsb.sourceforge.net the Linux TextBased Studio guide === AND MY PERSONAL PAGES AT: === http://www.juliencoder.de ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [ot] capitalising words in a shell-script
On Sat, 2008-09-27 at 12:04 +0200, Emanuel Rumpf wrote: Still in planning stage, but maybe not that far away: http://sourceforge.net/projects/cleese/ Solutions of simple problems, demanding several complex packages to be piped into one each other, does not take my fancy. Well... some unix gurus would claim here that unix piped *simple command tools* i.o. to accomplish *complex tasks*... depends on the vew ;-)) Maybe I was a a bit too harsh? There certainly are times when all you care about is getting the job done quickly as well as correctly. A UNIX guru/sysadmin will often be confronted with unique questions like: - Where the f*** did I misplace that shit and how to incorporate it into our new database from insert vendor, which we are gonna live with for the foreseeable future ... The next time shit happens, it will be a different situation, craving for yet another new approach. And it can most probably be solved once more by using standard tools. At home I have bits and pieces of audio related stuff that is not really working the way they were intended (yet.) They are all written as typical unix filters, the one piping into the next eventually arriving at either ALSA or OSS. This is for prototyping and evaluation of ideas. Real applications loops around similar ideas, but on a scale of every damned millisecond rather than the relaxed ALSA defualt of a second or so. This is where that other idea from KR comes into play. Real unix systems comes with a C-compiler that will optimze and vectorize your scribblings into something that is actually useful. I haven't dared to open the link you provided, but given past experiences, by the time I realize that the world is going to the dogs, my friends hardly raises an eyebrow and only says: - We told you so! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] Specification issues in open systems
The following is a cross-post of an exchange that took place on the rosegarden-devel mailing list. I'm posting it here because I think it hints at something fairly serious with the current state of open audio specifications and issues with their implementation. It is not my intent to start a flame war. I come at this with over twelve years of involvement (albeit chiefly at a hobbyist level) with audio development and production on windows system (predominantly VSTis). I've used linux since the late nineties, but these issues have become more important to me since fully ditching Windows about 18 months ago. The open source philosophy has always been that, if something were not to your tastes, you were completely free to build it, or alter something else. This is true, and one of the things greatly appreciated about the system. The key issue, though, is the ability to use that facility; sometimes it is not as available as it appears. There are a great many people who would offer much more to open audio, I feel, but issues like the following need to be addressed. all the best, Chris Williams Chris Williams yikyak wrote: Chris Cannam wrote: Chris Williams yikyak wrote: Hello, I've been developing a toy DSSI plugin, partly to become more familiar with the spec and partly as a platform for writing base code for use with less toy instruments. I've been using Rosegarden and jack-dssi-host as test hosts. All was going well until I increased the number of DSSI / LADSPA output audio ports in the plugin. For some reason, I expected that rosegarden would create extra synth channels in the audio mixer for these outputs, but this didn't happen. Instead, one 'synth' audio channel was maintained in the mixer for the synth, out of which all outputs could seemingly be heard and controlled globally. Does Rosegarden mix-down all the audio outputs of a given synth before feeding the signal to its own internal signal path, or am I misunderstanding something / being an idiot? The number of outputs shows up correctly in the synths 'controls' dialog along with its ID, but this seems to be the only place at which they're discernible outside of the synth. (I'm using v.1.7.0 from Arch's repository). No, you aren't misunderstanding anything. Rosegarden is very simplistic in this respect -- it mixes the number of audio outputs up or down to match the number of channels on the track, which is always either 1 or 2 depending on whether the stereo button in the instrument parameters is pushed in or not. If the aim is to accept multi-MIDI-channel input and send multi-channel output in order to support multiple effective instances on separate tracks, the DSSI way to do that is to have several actual instances (perhaps sharing data behind the scenes) and then call run_multiple_synths once for all of them instead of run_synth on each one. Rosegarden will do this if you have the same plugin set for more than one track (and it supports run_multiple_synths). Unfortunately, that mechanism is rather different from any other plugin format. Thanks Chris, that's just the information I was looking for. I was thinking more of the situation where where you have *single*-midi-channel input but, as with some synths and samplers, want to run the output to different banks of effects (e.g. LADSPA plugins) depending on the specific midi note or the range in which that note lies (output groups). This seems theoretically possible under DSSI using only run_synth() (given an idiosyncratic parsing of the DSSI spec) but not if the host routes all output ports through the same audio channel. At the same time, I can see the problem from the host developers' perspective: the DSSI spec uses LADSPA's port system and there's no good reason for an effect's output ever to be routed to multiple 'host audio channels'. The two other ways of doing it would seem to be: 1) Incorporate a 'channel' system and ladspa hosting system *internal* to the instrument which would then only ever need a stereo output to the host (the massive downside of this being that it unnecessarily replicates complex functionality already provided by the host); or 2) Use run_multiple_synths() in a hackish manner for which it probably wasn't fully intended, as you'd be writing to separate LADSPA handles but essentially using only one midi event queue (this would also have the nasty side effect of requiring multiple redundant instances simply to use their output ports). You could probably do something equally nasty by playing with the descriptor returning and instantiate functions. Anyway, thanks again. It's not a Rosegarden-specific issue, I know; more strangeness in the DSSI spec coupled with my own ignorance. I've been thinking about this some more, and can't let it lie. It seems to me that there's definitely a bug or broken implementation involved somewhere. Under jack-dssi-host, if I request n outputs, I get n
Re: [LAD] Specification issues in open systems
On Sat, 2008-09-27 at 14:04 +0100, yikyak wrote: The following is a cross-post of an exchange that took place on the rosegarden-devel mailing list. I'm posting it here because I think it hints at something fairly serious with the current state of open audio specifications and issues with their implementation. I don't have anything particularly useful to add to this discussion, but I do want to note that I could trawl back through my archives from the vst-plugins list and dig up at least a half dozen examples of similar behaviour differences between hosts in that world. Every time, the plugin authors have to detect which host they are running under and alter their behaviour. Nobody likes it and occasionally a host author modifies their software to be more like the rest of the bunch. I don't think your issue is with open audio specifications, its with API specifications in tiny little application niches. Good luck with resolving the issue. We'll use it if and when Ardour supports DSSI :) --p ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
On Sat, Sep 27, 2008 at 4:39 PM, Paul Davis [EMAIL PROTECTED] wrote: On Sat, 2008-09-27 at 14:04 +0100, yikyak wrote: The following is a cross-post of an exchange that took place on the rosegarden-devel mailing list. I'm posting it here because I think it hints at something fairly serious with the current state of open audio specifications and issues with their implementation. I don't have anything particularly useful to add to this discussion, but I do want to note that I could trawl back through my archives from the vst-plugins list and dig up at least a half dozen examples of similar behaviour differences between hosts in that world. Every time, the plugin authors have to detect which host they are running under and alter their behaviour. Nobody likes it and occasionally a host author modifies their software to be more like the rest of the bunch. I don't think your issue is with open audio specifications, its with API specifications in tiny little application niches. Good luck with resolving the issue. We'll use it if and when Ardour supports DSSI :) --p When the VST spec first came out, there was no such trouble (there were plenty of other problems ...) as the VST apps were the only ones that supported it. I'm not talking about a minor issue here; it's to do with how and whether plugin hosts respect the requests the plugins make of them. Requesting multiple outputs worked perfectly under steinberg's stuff, it worked perfectly under Reason, it worked perfectly under Logic (back before Apple dropped it). I don't have the VST spec to hand, but there were mechanisms (in the post-2 variants anyway) for requesting resources and then being told whether you could have them or not and, if not, how many you could have. Every single Native Instruments VI used this facility, as did many others. Furthermore, in the VST spec, there was a very easy way to determine the host under which you were running. IHostApplication::getName() and IIHostApplication::getVersion() come to mind, but I may be wrong about the exact details. There is no equivalent under DSSI (or LV2 as best I can gather). As part of the testbed application I'd been building, one of the first things I implemented was a logger in the gui so I could see what was going on. This is the output from the plugin bootstrap on Rosegarden: INTERNAL [27-09-2008 17:04:59.232 BST] : Starting ... INTERNAL [27-09-2008 17:04:59.241 BST] : Parsed Host Info: DSSI Hostname: yerupaja.yikyak.org DSSI Port: 17556 Basepath: /plugin/dssi/1/synth/phool_synth PluginLibrary: phool_synth.so PluginLabel: phool_synth PluginInstanceID: Rosegarden: Synth plugin #1 GUI (this) Hostname: yerupaja.yikyak.org GUI (this) Hostaddr: 192.168.0.2 INTERNAL [27-09-2008 17:04:59.252 BST] : Starting Listening ... INTERNAL [27-09-2008 17:04:59.266 BST] : Listener up on GUI Port 35095 INTERNAL [27-09-2008 17:04:59.269 BST] : DSSI host resolved to 192.168.0.2 SENT [27-09-2008 17:04:59.275 BST] : /plugin/dssi/1/synth/phool_synth/update osc.udp://192.168.0.2:35095/plugin/dssi/1/synth/phool_synth RECEIVED [27-09-2008 17:04:59.292 BST] : Received /configure Command: __ROSEGARDEN__:__RESERVED__:ProjectDirectoryKey /home/chris/rosegarden/ RECEIVED [27-09-2008 17:04:59.293 BST] : Received /program Command: 0 0 RECEIVED [27-09-2008 17:04:59.293 BST] : Received /show Command: and this the equivalent output from jack-dssi-host: INTERNAL [27-09-2008 17:00:13.988 BST] : Starting ... INTERNAL [27-09-2008 17:00:13.998 BST] : Parsed Host Info: DSSI Hostname: yerupaja.yikyak.org DSSI Port: 10596 Basepath: /dssi/phool_synth/phool_synth/chan00 PluginLibrary: phool_synth.so PluginLabel: phool_synth PluginInstanceID: channel 0 GUI (this) Hostname: yerupaja.yikyak.org GUI (this) Hostaddr: 192.168.0.2 INTERNAL [27-09-2008 17:00:14.009 BST] : Starting Listening ... INTERNAL [27-09-2008 17:00:14.024 BST] : Listener up on GUI Port 47687 INTERNAL [27-09-2008 17:00:14.027 BST] : DSSI host resolved to 192.168.0.2 RECEIVED [27-09-2008 17:00:14.033 BST] : Received /program Command: 0 0 RECEIVED [27-09-2008 17:00:14.033 BST] : Received /show Command: SENT [27-09-2008 17:00:14.033 BST] : /dssi/phool_synth/phool_synth/chan00/update osc.udp://192.168.0.2:47687/dssi/phool_synth/phool_synth/chan00 Now, granted, you could arguably host-detect Rosegarden from the plugin's instanceID or from the key-value sent to /configure, but there's nothing in the spec to guarantee that should be there, and there's nothing to say it won't change on a whim in future. There's *nothing* about the jack-dssi-host output, however, that would enable the client to discern where it was getting its service from. it's tricky to argue that clients should overcome holes in the spec or a given implementation if there's nothing in the spec that even guarantees having an ability to do that in the first place. I can't see this as being anything other than
Re: [LAD] Specification issues in open systems
On Sat, 2008-09-27 at 18:49 +0100, Chris Williams wrote: [ a lot of stuff ] are you seriously asking me to pull out my examples from vst-plugins over the last 5 years? yes, VST doesn't have the particular problem you are facing, but it has plenty of others. you want the most egregious? you tell me where in the VST spec it details which functions are called from which host thread. i could continue at quite some length ... i'm not trying to push back against your complaint. i'm just pointing out that the type of issue you're facing is actually really quite common in audio apps and with plugin APIs on different platforms. in implementing AudioUnit support in Ardour i ran into quite a lot of really significant problems which could only be solved using google-fu to pull answers from the coreaudio email list. none of the issues raised on that list have been documented by Apple and none of them have changed the API for AudioUnits in at least 5 years. every host developer and quite a few plugin authors have to face these over and over. we do it, we fix (most) of the problems, and we forget about it (mostly because we have no control over what apple does). i am really not taking you to task for your observations on DSSI - from what you've written it really does sound like a bit of mess in this repsect, and quite possibly LV2 as well. but .. i am not entirely clear why you've approached the problem in the way you have. your email contained a lot other claims about linux audio in general. i think that broad claims about this little world are a bit silly. speculations on why linux audio is in whatever state it is in generally seem to miss out on a number of important details and they also tend to skip the fact that this is a story written by a relatively small number of self-admittedly imperfect and insufficiently devoted people. most of us do not have the time or inclination to focus on newbies to audio programming on linux, even if we recognize that this is a problem and wish it was otherwise. --p ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] multiple ICE1712 sound cards (as one huge soundcard)
Hello Christian! I suppose it's more a configuration issue. Do you have ALSA compiled in the kernel or as a module? I believe, but maybe wrong here, that modules are easier to configure. You do need to enter both cards in your modprobe.d directory or whatever your systems place is for the kernel module configuration. HTH, I'm out of it right here! :-( Kindest regards Julien Music was my first love and it will be my last (John Miles) FIND MY WEB-PROJECT AT: http://ltsb.sourceforge.net the Linux TextBased Studio guide === AND MY PERSONAL PAGES AT: === http://www.juliencoder.de ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
On Sat, Sep 27, 2008 at 08:18:39PM +0200, Paul Davis wrote: most of us do not have the time or inclination to focus on newbies to audio programming on linux, even if we recognize that this is a problem and wish it was otherwise. I spend on average something like the equivalent of half a working day each week on responding to off-list requests for support on some aspect of linux audio programming. The simple fact is that creating a 'major' audio app is not a simple task *on any system* and requires a mix of skills and knowledge that take their time to build up and mature. It's just not supposed to be easy for a relative newbie - believing that it should be may fit some political agenda but is rather foolish. Linux may democratise access to audio and other media production tools, and that's a good thing, but it does not do so by creating 'instant experts'. Regarding the original topic of this thread, I'd like to make two comments. First, why should a complete instrument, taking in MIDI and producing audio, be a plugin in Rosegarden or any other sequencer ? It would be much more useful as a standalone app, and probably *a lot* easier to develop. I wouldn't think for even a fraction of a second to write Aeolus as a plugin - it would be an exercise in self-torture of the third degree. Second, the life of Rosegarden's developers would have been a lot easier if they had just concentrated on trying to be the best MIDI sequencer rather than also a complete multitrack audio recorder, a mixer, and a host to software instruments. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
Fons Adriaensen wrote: First, why should a complete instrument, taking in MIDI and producing audio, be a plugin in Rosegarden or any other sequencer ? It would be much more useful as a standalone app, and probably *a lot* easier to develop. I wouldn't think for even a fraction of a second to write Aeolus as a plugin - it would be an exercise in self-torture of the third degree. Except the biggest advantage of plug-ins is session state saving: When I have one master app that stores the states of all of my plug-ins, I can save out the session, and recall it later exactly as I saved it. Where is the functionality in JACK for that? I know that LASH has been making headway into that issue, but my understanding is that it has been an uphill battle. Believe it or not, this is a major showstopper for a lot of people. When I save out a session and pull it up later, I want it to come back up the way it was when I saved it. I don't want to have to mess with bringing up every program I was using and finding the preset I was using in each one. Of course, my experience with JACK is limited, and if it turns out the session state saving is in there, then I simply haven't found it yet, and you can ignore this email. Indeed, you can take this email for all it's worth. I've just about gotten to the point where I've stopped caring. -- Darren Landrum ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
On Sat, 2008-09-27 at 22:06 +0200, Fons Adriaensen wrote: First, why should a complete instrument, taking in MIDI and producing audio, be a plugin in Rosegarden or any other sequencer ? It would be much more useful as a standalone app, and probably *a lot* easier to develop. I wouldn't think for even a fraction of a second to write Aeolus as a plugin - it would be an exercise in self-torture of the third degree. Fons, you know I broadly agree with you, but a substantial fraction of the world's software instrument developers appear to feel otherwise. I can't think of a single major out-of-the-box software instrument for windows or OS X that hasn't been implemented as a plugin. the things that are only stand-alone apps are generally synthesis environments or have associated h/w (examples: kyma/capybara, max/msp, reaktor, and so forth, along with all the music-N derived synthesis languages). i haven't heard a single commercial developer complain about being forced to do things as a plugin, only about the details of it. --p ps. i think that even reaktor may be available as a plugin, and max/msp patches can be implemented as plugins by combining them with a core max runtime library. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
On Sat, 2008-09-27 at 16:35 -0400, Darren Landrum wrote: Fons Adriaensen wrote: First, why should a complete instrument, taking in MIDI and producing audio, be a plugin in Rosegarden or any other sequencer ? It would be much more useful as a standalone app, and probably *a lot* easier to develop. I wouldn't think for even a fraction of a second to write Aeolus as a plugin - it would be an exercise in self-torture of the third degree. Except the biggest advantage of plug-ins is session state saving: When I have one master app that stores the states of all of my plug-ins, I can save out the session, and recall it later exactly as I saved it. Where is the functionality in JACK for that? something must be going wrong with the world darren. we're in agreement with each other twice in the same month :)) --p ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
Paul Davis wrote: something must be going wrong with the world darren. we're in agreement with each other twice in the same month :)) It must be something in the water. :-P So... Why couldn't session states be saved as part of JACK? I realize it can be argued that it isn't within the scope of JACK, but... Isn't it, kinda? It's an important feature, and it has to get implemented *somewhere*. Of course, it makes the most sense that session states should be saved and recalled by the host. Isn't that also a part of what LASH is trying to accomplish? Unfortunately, I have to plead ignorance here, as I'm no coder, just a math head trying to make some new plug-ins, and getting nowhere, I might add. I still regard LV2 as a potentially powerful system for creating and handling virtual instruments and effects, but the right extensions (events and MIDI, and UI) would have to be implemented by the popular hosts. That's my largely ignorant opinion, anyway. -- Darren Landrum ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
On Sat, Sep 27, 2008 at 10:39:32PM +0200, Paul Davis wrote: Fons, you know I broadly agree with you, but a substantial fraction of the world's software instrument developers appear to feel otherwise. I can't think of a single major out-of-the-box software instrument for windows or OS X that hasn't been implemented as a plugin. On of the reasons being that on Windows or OSX in their official incarnations there is nothing like Jack. A single app on those systems is completely isolated. That is not the case in Linux. i haven't heard a single commercial developer complain about being forced to do things as a plugin, only about the details of it. Well, a 'rich' plugin standard has to provide almost everything that the operating system provides: audio, midi, GUI, network,... So why not use the system as your host ? All it takes is a good session manager. Existing plugin standards on Linux have been used to to implement a number of quite different things: A. Effects, general audio processing tools. B. Soft-synth modules, as in AMS or Om. C. Complete instruments. The requirments for each of these are quite different. It's somewhat naive to expect that a *simple* plugin standard could support all of those in an optimal way. Also a host that would support all of these would be multi-headed monster. LV2 started off in the right way, but in the usual attempt to make things as simple as possible for the uneducated user, what resulted was too minimal to support anything but the simplest use cases. Porting Aeolus to LV2 would require a number of absolutely non-trivial extensions, Jconv would require a lot more, etc. So if I wanted to port any of these I'd also have to write the host. If that host has to be useful for anything else than being a shell to my own apps it should also include all extensions needed by all other plugins. And a sequencer. And an audio recorder. And in the end neither Aeolus nor Jconv would work in Rosegarden or any other host, unless those authors would include my extensions as well. And I bet a 10 bottles of Amarone they will not. Finally, users 'expect' things. Yes. They also expect, at the age of 20, a house and garden and swimming pool, two cars, a 50 TV, a fixed job, two three-week holidays in a sunny place, free health care and a pension. All for free and without any effort from their side. You can build entire belief systems on this, and even a market, but we've seen during the last weeks what is the result of doing that. As a writer of software that you provide for free, the most stupid thing you can do is to be market- driven. You just waste your time and degrade the quality of your work. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
Fons Adriaensen wrote: Well, a 'rich' plugin standard has to provide almost everything that the operating system provides: audio, midi, GUI, network,... So why not use the system as your host ? All it takes is a good session manager. This is clearly a repeating theme here. Is LASH the solution to this issue, then? I remember looking at the documentation for it and thinking it didn't look too difficult to implement. Reaktor works by having a standalone app for designing new ensembles (a complete instrument, effect, or combination thereof), and the VST plug-in is basically the core engine with the GUI engine running the ensemble without all of the graph-y back-end editing features. I don't know any of the details on how they made this work. I get the impression that the Emu Emulator X/X2 sampler works the same way. Gigasampler is not a plug-in, but used Propellerhead's ReWire, perhaps the closest analog to JACK on Windows. ReWire, though, can save the state of the slave programs wired in to the host app. I don't know how they accomplish this. (Big fat lot of help I am, I know.) I'd still like to think that there is still an innovative solution to this problem, and that we are the ones destined to find it. Time for some brainstorming, perhaps? -- Darren Landrum ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
Darren Landrum wrote: I'd still like to think that there is still an innovative solution to this problem, and that we are the ones destined to find it. Time for some brainstorming, perhaps? Sorry for replying to my own message. If something like this is to be solved, it should be tied to the host, I think. In other words, the state of my previous session has to restore itself upon re-loading the session file in Ardour|Qtractor|Rosegarden (take your pick). That means the host has to have the ability to run the other programs and set up the JACK graph connections. Is this even remotely possible? -- Darren Landrum ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Specification issues in open systems
On Sat, 2008-09-27 at 19:03 -0400, Darren Landrum wrote: Darren Landrum wrote: I'd still like to think that there is still an innovative solution to this problem, and that we are the ones destined to find it. Time for some brainstorming, perhaps? Sorry for replying to my own message. If something like this is to be solved, it should be tied to the host, I think. In other words, the state of my previous session has to restore itself upon re-loading the session file in Ardour|Qtractor|Rosegarden (take your pick). That means the host has to have the ability to run the other programs and set up the JACK graph connections. Is this even remotely possible? LASH is intended to do all this (and maybe more too). Its just that its development process has, for all kinds of reasons, not been accompanied by the same general gee, lets all jump on this that accompanied LADSPA and JACK. When its done and widely adopted, this will work the way you want it to. --p ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
