Menu
▾
▴
linuxsampler-devel
|
From: <be...@ga...> - 2004-01-10 11:40:40
|
Tobias you did reply only to me privately (by accident) so I'm forwarding it to the list. List members, please when replying only reply to the list, CCs to members that are on list are useless and will result in annoying duplicate mails :-) Anyway a few thoughts: since we face the MIDI over ethernet problem too. Why not do both in one rush ? I propose the following: since the windows box must send the sync packet to wake up LS. That sync packet could contain the midi data The bandwidth of a MIDI channel is usually 31250kbit/sec which is about 3000bytes/sec, quite low for an ethernet network. So assume we use 128 sample fragments. (but make it configurable of course) at 44100Hz this means 44100/128 = 344 packets per second sent by LS to the windows box and 344 sync packets sent from the windows box to LS. The sync packet carries no payload and we can use it to transmit midi data. So I'd say define a maximum number of MIDI bytes per sync packet value. Eg 128. This means 128*344 a virtual midi channel with a bandwidth of 44KB/sec. Which is ten times as high as standard MIDI. So on the windows box we need to write a small midi driver that listens to local midi events and puts them into the outgoing sync packet queue. In the rare case where we achieve the maximum midi bytes per sync packet value, we can send the rest of the MIDI bytes with the next sync packet. LS will simply parse the incoming midi bytes that came with the sync packet and if there are incomplete MIDI messages (eg only the note on byte and pitch value but the velocity byte has not been transmitted yet), it will simply let it sit in a local queue/fifo and parse it at the next cycle. Its very simple. Regarding ASIO: I'm not sure if ASIO is the way to go, how about going directly VST ? VST is supported by any professional application under Windows plus it has builtin MIDI which means you don't need to write a MIDI driver the plugin directly gets the MIDI events from the sequencer. Plus the VST callback is called exactly ( process() ) for each audio fragment processed, wich makes the whole stuff even more simple. Comments ? cheers, Benno http://www.linuxsampler.org Scrive Tobias Erichsen <t.e...@gm...>: > > > > -----Original Message----- > > From: lin...@li... > > [mailto:lin...@li...]On Behalf Of > > be...@ga... > > Sent: Friday, January 09, 2004 11:13 PM > > To: lin...@li... > > Subject: Re: [Linuxsampler-devel] Win32-Integration-Proposal > > > > > > Excellent Tobias ! > > That's exactly what future professional studio users will need. > > That you already wrote an ASIO driver is very very valuable. > > > > I'd opt for UDP for the transmission protocol. > > I want to send the stuff using RTP which is based on UDP > and is specifically used for audio & video transmission > stuff... > > > (without retransmission since in local networks > > the packet loss ratio is basically zero, and retransmission would kill > > latency). > > That's right - at work we are doing Voip-stuff, which for the > same reasons is using UDP/RTP because retransmissions are > bad for realtime-data... > > I thought that I would synchronize the stuff to the clock > of the PC-soundcard, as obviously this is the one driving > the sequencer as well... so whenever the soundcard on the > pc finishes a block of audio-data, i will send a packet > to the other side... which then would cause ls to send > a new packet... > > Tobias > ------------------------------------------------- This mail sent through http://www.gardena.net |
|
From: Peter R. <pet...@de...> - 2004-01-10 11:59:08
|
Forgive me for going slightly OT, but: Gigabit ethernet of course has a much higher bandwidth than 100 mbit, but I once read a post from Matthias Carsten from RME who stated that gigabit puts a rather high load on the CPU due to increased interrupt handling and (I think) he said it had a bad effect on the performance of audio cards. Can anyone comment on this? TIA, Peter Roos Netherlands -----Original Message----- From: be...@ga... [mailto:be...@ga...] Sent: Saturday, January 10, 2004 12:48 To: Linux-Sampler Subject: Re: [Linuxsampler-devel] Win32-Integration-Proposal While 1394 is nice and gives some real time guarantees it has the drawback that it's harder to buy long cables, switches build large networks etc. I guess such setups are much more expensive. If you dedicate ethernet to audio it is very reliable and except in some troublesome cases the packet loss ratio and high latencies are basically zero. Even with a cheap D-Link 8 port switch I achieve the full 100Mbit and constant 0.1-0.2 msec ping times between two linux boxes. The poor man's linuxsampler cluster is much more likely to use ethernet than firewire since it has a lower TCO. That said firewire will be handy too but for now let's put the main weight on ethernet. Indeed, 2004 will become an interesting sampling-year :-) cheers, Benno http://www.linuxsampler.org Scrive Mark Knecht <mar...@co...>: > On Fri, 2004-01-09 at 15:17, Christian Schoenebeck wrote: > > I think a JACK client that implements the network protocol would be a > better > > idea. > > There is a new Jack client written by Bob Ham for doing Jack over 1394 > also. I haven't had a chance to test it, but with more bandwidth and > guaranteed delivery times 1394 could offer something here also. It would > be nice to actually send MIDI requests to LS and be able to return audio > over the same cable in a very deterministic way. > > Anyway, fun to think about... > > Cheers, > Mark > ------------------------------------------------- This mail sent through http://www.gardena.net ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Linuxsampler-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Peter R. <pet...@de...> - 2004-01-10 12:02:20
|
Isn't it possible to change the From address to "Linux-Sampler" in the mails from the listserver? I nearly made the same mistake in my first post :-) -----Original Message----- From: be...@ga... [mailto:be...@ga...] Sent: Saturday, January 10, 2004 12:41 To: lin...@li... Subject: RE: [Linuxsampler-devel] Win32-Integration-Proposal Tobias you did reply only to me privately (by accident) so I'm forwarding it to the list. List members, please when replying only reply to the list, CCs to members that are on list are useless and will result in annoying duplicate mails :-) |
|
From: Mattias H. <ma...@mu...> - 2004-01-10 14:38:45
|
"Instead" would make us Sonar users unhappy due to the underwhelming ReWire integration... "Also" is more like it. Of course, once you do one or both of these, plenty of users will scream "how about a proper DXi implementation"... :-) /Mattias > Instead of VST, or in addition to VST, how about ReWire? I'm not a user > of either of these, but I think ASIO and VST will leave out Pro Tools > (my platform) while ReWire is supported. |
|
From: Mark K. <mar...@co...> - 2004-01-10 15:15:41
|
On Sat, 2004-01-10 at 06:43, Mattias Henningson wrote: > "Instead" would make us Sonar users unhappy due to the underwhelming ReWire > integration... "Also" is more like it. Of course, once you do one or both of > these, plenty of users will scream "how about a proper DXi > implementation"... :-) > > /Mattias > Yes, it's an age old story, and being on the Pro Tools side I'm usually the loser. Hope you don't blame me for lobbying... ;-) - Mark |
|
From: <be...@ga...> - 2004-01-11 00:57:00
|
About Rewire: this post seems rather discouraging, their license seems incompatible with open source: http://techweb.rfa.org/pipermail/portaudio/2003-April/001827.html I still think a VST windows network frontend for LS is the way to go (at least during the initial phase). there are tons of VST hosts and wrappers so I think a VST module would make many of the windows audio users happy. Tobias, comments ? [ VSTi proposal of Mattias .... ] > > This is exactly what I was about to suggest yesterday. From a user > perspective this is much more usable than some midi driver + audio driver > solution. I'm using FXTeleport on the Windows platform today and this is > exactly how it works. I don't know what you think about this but why not > integrate this solution with FXT? FXT already have the Win32 parts ready, > stable and working. What would be needed to accomplish this is: About FXT, ok but the problem is we want a free windows client. I doubt he will make a (even closed source) client for us. Or perhaps he will open the protocol and we will use a FXT-compatible protocol. So that LS works with both our free client and with FXT ? Or alternatively we develop our own network protocol and since the specs are open the FXT guy can add support to FXT so that you can use an LS machine and a FXT client. There are many possibilities, but I guess that he will try to keep his protocol closed in order to avoid cannibalizing his sales. Anyway network streaming is not as hard as one might think, Some tunable client buffering and it works. Writing a VSTi is not hard either, the APIs are really straightforward. Since LS usues a TCP socket for the GUI controls and since we plan to use the Qt library (which allows for crossplatform GUI code) so we can embed the GUI controls directly into the VSTi without problem. This would be userfriendly since you have an all-in-one solution. > > * A "server" client that lives on the Linux server that connects to the FXT > host on the sequencer machine. > * A VSTi that controls LS from the Win32 machine, sends midi to, and > receives audio from LS. Maybe this VSTi could even incorporate a Windows > based remote control for LS. Exactly, see above. > > This idea is of course depending on whether Max, the developer of FXT, is > willing to open up he communicaton specs he's using... I actually wrote him > a mail yesterday with the idea as I've been working with him quite closely > with a couple of things lately. I'll let you know whether this would be at > all possible when I hear from him. ok ! PS: PeterRoos: what did you mean with your post on the NS forum ? ----- Would it be possible to run LinuxSampler as a (system) service (or as sampler player "server") with the user interface on a different box, say Win or Mac? I think that would be a really cool distribution of the system's components. It would allow users to keep working in their familiar environment, after installing and configuring the LS. ---- It's exactly what we are discussing about :-) Or am I missing something ? cheers, Benno http://www.linuxsampler.org Scrive Mark Knecht <mar...@co...>: > Hey, I appreciate the support, but DigiDesign has always made it sort of > hard to support them. Their RTAS stuff requires special agreements to > get the specs and all. It's always been difficult for us Pro Tools > folks. Digi added ReWire support with version 6. I don't have any ReWire > instruments, so I cannot even say if it works or not. > > LS will support Pro Tools right out of the box. It's an external sampler > just like GSt, so I can use it. It's just another MIDI device. That's > not bad. > > As far as this whole Windows GUI thing goes, I *think* that this would > allow VST users to see it within their sequencer GUI, right? I guess the > goal here is to be able to control what samples are being loaded in > specific songs on specific tracks and MIDI channels? That would be > really cool to have in Pro Tools also, I must admit, but I've got so > little in this environment that I'm just used to begging! ;-) > > ------------------------------------------------- This mail sent through http://www.gardena.net |
|
From: Tobias E. <t.e...@gm...> - 2004-01-11 16:40:16
|
> -----Original Message----- > From: lin...@li... > [mailto:lin...@li...]On Behalf Of > be...@ga... > Sent: Sunday, January 11, 2004 1:57 AM > To: Linux-Sampler > Subject: RE: [Linuxsampler-devel] Win32-Integration-Proposal > > > About Rewire: > this post seems rather discouraging, their license seems > incompatible with > open source: > http://techweb.rfa.org/pipermail/portaudio/2003-April/001827.html > > I still think a VST windows network frontend for LS is the way to go > (at least during the initial phase). > there are tons of VST hosts and wrappers so I think a VST module would > make many of the windows audio users happy. > > Tobias, comments ? Sounds pretty good... I have done a little bit of work with VSTs (was thinking about developing my own vst-host before I went off with the asio2ks project) - i'm not really that much of a gui-designer - and a vst-host needs some good gui. I think a VST-instrument needs a good gui also, but someone else could contribute there, as I really don't have any experience with QT... If you guys think this is ok, I'd like to do some stuff for the network layer and perhaps even the vst-wrapper for the win32- part. I'd use rtp for the audio-signals (same stuff that is used for VoIP), there's also a draft for midi over rtp, but I'm not sure if there's any other prot that would be better for midi... I have not invested that much of time looking at the ls-control- prot-spec yet, I'd need to do this the next couple of days... Tobias |
|
From: Christian S. <chr...@ep...> - 2004-01-11 16:53:31
|
Es geschah am Sonntag, 11. Januar 2004 17:42 als Tobias Erichsen schrieb: > Sounds pretty good... I have done a little bit of work with > VSTs (was thinking about developing my own vst-host before I > went off with the asio2ks project) - i'm not really that much > of a gui-designer - and a vst-host needs some good gui. No problem, Rui already works on a Qt GUI for LS, so you don't have to write your own GUI. You simply would have to embed his Qt GUI in your VSTi host. Should be quite easy for you. CU Christian |
|
From: Mark K. <mar...@co...> - 2004-01-11 17:12:05
|
On Sun, 2004-01-11 at 08:42, Tobias Erichsen wrote: > Sounds pretty good... I have done a little bit of work with > VSTs (was thinking about developing my own vst-host before I > went off with the asio2ks project) - i'm not really that much > of a gui-designer - and a vst-host needs some good gui. > Cool! Good to have another interested developer. I don't mean to throw water on any folks fire about doing a Windows-based front-ends, but just to lobby for a bit more balance. If you or others could become more interested in the internals of LS, then the real tool could move forward more quickly. As a potential user of LS I will point out though that even if we had a gorgeous PC/Mac VST type interface, we'd still be talking to a version of LS that is missing conservatively at least 15-20 features it needs to be compatible with even my desired GSt platform, much less adding all the interesting stuff other folks are looking for like Kontakt & Battery type features. (And I'll list the features if requested...) So, do what you want since that's the way Open Source development works, but at least consider jumping in and adding features to LS itself. If I had the talent you guys do that's where I'd try to put my efforts. It wouldn't be easy, but I think the most valuable. None the less, whatever you and others decide to do will be of great value and it's good to have you here. Cheers, Mark |
|
From: Mattias H. <ma...@mu...> - 2004-01-11 23:11:25
|
<be...@ga...> wrote: > > About FXT, ok but the problem is we want a free windows client. > I doubt he will make a (even closed source) client for us. > Or perhaps he will open the protocol and we will use a FXT-compatible protocol. > So that LS works with both our free client and with FXT ? > Or alternatively we develop our own network protocol and since the specs > are open the FXT guy can add support to FXT so that you can use an LS machine > and a FXT client. > There are many possibilities, but I guess that he will try to keep > his protocol closed in order to avoid cannibalizing his sales. Ok, it seems he's actually been planning a Linux version of the FXT server. No planned timetable though so far and without no doubt the Mac version (OS X btw so it's not too different) has precedence right now... Anyway, LS would need to support Jack or LADSPA in order to work with the FXT server when it finally shows up. I'm very new here but didn't I at least read something about Jack support the other day? If that is the case both solutions (FXT and the "native" LS solution) could be used. > Anyway network streaming is not as hard as one might think, > Some tunable client buffering and it works. > Writing a VSTi is not hard either, the APIs are really straightforward. Agreed, this is at least something I can confirm. I've touched network streaming in a few projects and I've messed a bit with the VST SDK too lately and it's very straight-forward. > Since LS usues a TCP socket for the GUI controls and since we plan > to use the Qt library (which allows for crossplatform GUI code) so > we can embed the GUI controls directly into the VSTi without problem. > This would be userfriendly since you have an all-in-one solution. Very cool solution. /Mattias |
|
From: Christian S. <chr...@ep...> - 2004-01-12 00:11:26
|
Es geschah am Montag, 12. Januar 2004 00:15 als Mattias Henningson schrieb: > Ok, it seems he's actually been planning a Linux version of the FXT server. > No planned timetable though so far and without no doubt the Mac version (OS > X btw so it's not too different) has precedence right now... Anyway, LS > would need to support Jack or LADSPA in order to work with the FXT server > when it finally shows up. I'm very new here but didn't I at least read > something about Jack support the other day? If that is the case both > solutions (FXT and the "native" LS solution) could be used. Yeah, Jack will be added very soon to LS. We just slightly have to modify the structure of LS a bit for this, because the audio render loop is currently (due to Alsa) polling based. For Jack we'll need it event based, so Jack calls LS when it wants to have the next audio fragment to be rendered. This requires only little changes, it has to be done though. CU Christian |
|
From: Ryan <rui...@co...> - 2004-01-11 02:25:09
|
On Sat, 2004-01-10 at 18:57, be...@ga... wrote: > About Rewire: > this post seems rather discouraging, their license seems incompatible with > open source: > http://techweb.rfa.org/pipermail/portaudio/2003-April/001827.html > > I still think a VST windows network frontend for LS is the way to go > (at least during the initial phase). > there are tons of VST hosts and wrappers so I think a VST module would > make many of the windows audio users happy. Pluggo from cycling74 is a VST wrapper that does midi with Pro Tools, so I guess that'll allow interested PT professionals to access LS anyway. http://www.cycling74.com/products/pluggo.html -ry |
|
From: Mark K. <mar...@co...> - 2004-01-11 02:42:52
|
On Sat, 2004-01-10 at 18:25, Ryan wrote: > Pluggo from cycling74 is a VST wrapper that does midi with Pro Tools, so > I guess that'll allow interested PT professionals to access LS anyway. > > http://www.cycling74.com/products/pluggo.html > > -ry :-( - looks like Mac only? |
|
From: Ryan <rui...@co...> - 2004-01-11 06:42:52
|
On Sat, 2004-01-10 at 20:42, Mark Knecht wrote: > On Sat, 2004-01-10 at 18:25, Ryan wrote: > > > Pluggo from cycling74 is a VST wrapper that does midi with Pro Tools, so > > I guess that'll allow interested PT professionals to access LS anyway. > > > > http://www.cycling74.com/products/pluggo.html > > > > -ry > > :-( - looks like Mac only? Oh yeah (I'm so ignorant of the windows world lately, which is nice ;-) but I read on the site that windows development is on the way and soon to arrive. -ry |
|
From: Peter R. <pet...@de...> - 2004-01-11 10:27:31
|
Hi Benno, This newbie got carried away in his ignorance. LS is going to be soo cool! great architecture. I have been user interface designer for 9 years, after being software engineer (multitasking stuff and portable GUI's in Modula-2, long ago). I run my own 1 person company, Deltaworks :-) I will be following the UI parts with great interest, maybe I can once contribute some parts. Take care, Peter Roos (www.deltaworks.nl / www.PeterRoos.com) Benno wrote: PS: PeterRoos: what did you mean with your post on the NS forum ? ----- Would it be possible to run LinuxSampler as a (system) service (or as sampler player "server") with the user interface on a different box, say Win or Mac? I think that would be a really cool distribution of the system's components. It would allow users to keep working in their familiar environment, after installing and configuring the LS. ---- It's exactly what we are discussing about :-) Or am I missing something ? cheers, Benno http://www.linuxsampler.org |
|
From: Mattias H. <ma...@mu...> - 2004-01-10 12:08:40
|
Hi, I'm new here... I became interested in this project after Benno's post on the NorthernSounds forum (I didn't know about LS before that). I'm not a Linux user today, but I'm developing Windows software for a living and I'm running a pretty well equipped and fully booked studio the rest of my time... Anyway, I'm always interested in new solutions and this seemed to be interesting. I'll lurk on this list and maybe chime in when I have something to add. Since my Linux specific knowledge is near zero right now my contribution will mostly be in the idea/usage department. > I'm not sure if ASIO is the way to go, how about going directly VST ? > VST is supported by any professional application under Windows plus > it has builtin MIDI which means you don't need to write a MIDI driver > the plugin directly gets the MIDI events from the sequencer. > Plus the VST callback is called exactly ( process() ) for each audio > fragment processed, wich makes the whole stuff even more simple. This is exactly what I was about to suggest yesterday. From a user perspective this is much more usable than some midi driver + audio driver solution. I'm using FXTeleport on the Windows platform today and this is exactly how it works. I don't know what you think about this but why not integrate this solution with FXT? FXT already have the Win32 parts ready, stable and working. What would be needed to accomplish this is: * A "server" client that lives on the Linux server that connects to the FXT host on the sequencer machine. * A VSTi that controls LS from the Win32 machine, sends midi to, and receives audio from LS. Maybe this VSTi could even incorporate a Windows based remote control for LS. This idea is of course depending on whether Max, the developer of FXT, is willing to open up he communicaton specs he's using... I actually wrote him a mail yesterday with the idea as I've been working with him quite closely with a couple of things lately. I'll let you know whether this would be at all possible when I hear from him. /Mattias |
|
From: Mark K. <mar...@co...> - 2004-01-10 14:25:49
|
On Sat, 2004-01-10 at 03:40, be...@ga... wrote: > Regarding ASIO: > I'm not sure if ASIO is the way to go, how about going directly VST ? > VST is supported by any professional application under Windows plus > it has builtin MIDI which means you don't need to write a MIDI driver > the plugin directly gets the MIDI events from the sequencer. > Plus the VST callback is called exactly ( process() ) for each audio > fragment processed, wich makes the whole stuff even more simple. > > Comments ? Instead of VST, or in addition to VST, how about ReWire? I'm not a user of either of these, but I think ASIO and VST will leave out Pro Tools (my platform) while ReWire is supported. |
|
From: Ryan <rui...@co...> - 2004-01-10 22:48:12
|
On Sat, 2004-01-10 at 08:25, Mark Knecht wrote: > On Sat, 2004-01-10 at 03:40, be...@ga... wrote: > > > Regarding ASIO: > > I'm not sure if ASIO is the way to go, how about going directly VST ? > > VST is supported by any professional application under Windows plus > > it has builtin MIDI which means you don't need to write a MIDI driver > > the plugin directly gets the MIDI events from the sequencer. > > Plus the VST callback is called exactly ( process() ) for each audio > > fragment processed, wich makes the whole stuff even more simple. > > > > Comments ? > > Instead of VST, or in addition to VST, how about ReWire? I'm not a user > of either of these, but I think ASIO and VST will leave out Pro Tools > (my platform) while ReWire is supported. I have to agree. ProTools is THE professional audio application to many many (really most) studio engineers. VST and ASIO will interest home users and amateur musicians but in order for LS to make it's way into professional studios ProTools MUST be supported. Just my opinion, -ry |
|
From: Mark K. <mar...@co...> - 2004-01-10 23:28:37
|
> > > > Instead of VST, or in addition to VST, how about ReWire? I'm not a user > > of either of these, but I think ASIO and VST will leave out Pro Tools > > (my platform) while ReWire is supported. > > I have to agree. ProTools is THE professional audio application to many > many (really most) studio engineers. VST and ASIO will interest home > users and amateur musicians but in order for LS to make it's way into > professional studios ProTools MUST be supported. > > Just my opinion, > -ry Hey, I appreciate the support, but DigiDesign has always made it sort of hard to support them. Their RTAS stuff requires special agreements to get the specs and all. It's always been difficult for us Pro Tools folks. Digi added ReWire support with version 6. I don't have any ReWire instruments, so I cannot even say if it works or not. LS will support Pro Tools right out of the box. It's an external sampler just like GSt, so I can use it. It's just another MIDI device. That's not bad. As far as this whole Windows GUI thing goes, I *think* that this would allow VST users to see it within their sequencer GUI, right? I guess the goal here is to be able to control what samples are being loaded in specific songs on specific tracks and MIDI channels? That would be really cool to have in Pro Tools also, I must admit, but I've got so little in this environment that I'm just used to begging! ;-) |
Thanks for helping keep SourceForge clean.
X