Marc Lavallée said this at Mon, 19 Jan 2004 11:45:14 -0500:

On Mon, Jan 19, 2004 at 04:14:41PM +0000, Adam Lindsay wrote:

...

Mac users who are trying to get Jack going, be aware that Cycling 74 has released the free Soundflower driver, ...

Where's the source code?

I would suggest you take that up with Matt Ingalls, who seems to be the developer.

I should have specified free-as-in-beer.

adam

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay atl@comp.lancs.ac.uk Computing Dept, Lancaster University +44(0)1524/594.537 Lancaster, LA1 4YR, UK Fax:+44(0)1524/593.608 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Frank Barknecht said this at Mon, 19 Jan 2004 17:59:22 +0100:

It's promised to be released as "open source" later, as far as Cycling's press release states. Currently Soundflower is not free as in libre yet, I guess. Is there a license in the sit archive?

Not in the README that I can see.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay atl@comp.lancs.ac.uk Computing Dept, Lancaster University +44(0)1524/594.537 Lancaster, LA1 4YR, UK Fax:+44(0)1524/593.608 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Marc Lavallée odradek@videotron.ca writes:

On Mon, Jan 19, 2004 at 04:14:41PM +0000, Adam Lindsay wrote:

...

Mac users who are trying to get Jack going, be aware that Cycling 74 has released the free Soundflower driver, ...

Where's the source code?

I've read a release announcement somewhere (harmony-central, I believe) which says that the source will be released later on. No licensing information has been provided, IIRC.

Seems to me they're trying to compete with jack :) which BTW got the first open source merit award [http://www.opensource.org/osa/awards.php]

-- ./MiS

Frank Barknecht said this at Mon, 19 Jan 2004 17:56:40 +0100:

But doesn't Soundflower do anything else than the Jack Tools from http://www.jackosx.com/ ? Pd should be able to work out of the box with the CoreAudio-Jack wrapper included in the Jack Tools, or doesn't it?

To be honest, I don't know. I was very interested when I heard about Jack Tools being released, but it's not very clear on what it does and how it does it. I've just installed it now (need to restart to test).

The soundflower download is considerably smaller, so I have faith in it as a small, light shim, and I got it going with minimal effort. More choice can't hurt!

adam

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay atl@comp.lancs.ac.uk Computing Dept, Lancaster University +44(0)1524/594.537 Lancaster, LA1 4YR, UK Fax:+44(0)1524/593.608 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Hallo, Adam Lindsay hat gesagt: // Adam Lindsay wrote:

Frank Barknecht said this at Mon, 19 Jan 2004 17:56:40 +0100:

...

But doesn't Soundflower do anything else than the Jack Tools from http://www.jackosx.com/ ? Pd should be able to work out of the box with the CoreAudio-Jack wrapper included in the Jack Tools, or doesn't it?

To be honest, I don't know. I was very interested when I heard about Jack Tools being released, but it's not very clear on what it does and how it does it. I've just installed it now (need to restart to test).

The soundflower download is considerably smaller, so I have faith in it as a small, light shim, and I got it going with minimal effort. More choice can't hurt!

Well, as a Linux user, of course I am biased. I don't think, that fragmentation in this area (sound output, routing between apps) will benefit the general cause: more interoperability. I wished, that Cycling and Matt would have put their efforts into making Jack run on OS-X, instead of writing another software that basically does the same, but is not as powerful (yet, maybe). I see Jack as one major achievement of the Linux audio scene, that deserves more widespread use in applications (although I still cannot use it very well with Pd...)

ciao

Frank Barknecht _ ______footils.org__

Hallo, guenter geiger hat gesagt: // guenter geiger wrote:

...

(although I still cannot use it very well with Pd...)

hmm, thats bad to hear .. are there specific problems or is it just generally unusable ?

It works in general, but I'm bitten by the conflict, that graphic demanding patches when running Pd with "-rt" hangs either Jackd or Pd. I'm currently using pd-0.37-test3 by Miller with the small "higher" patch you posted on pd-dev today. If I open one of the patches in the "usecases" directory if my rradical-pd collection here http://footils.org/pkg/rradical-wip-040109.tgz Pd or jack (0.90.1 from Agnula) hangs after a short time (or Pd hangs immediatly, if I open the patch as a command line argument).

ciao

Frank Barknecht _ ______footils.org__

Hallo, guenter geiger hat gesagt: // guenter geiger wrote:

I'll try it out asap. Can you send me your .pdrc, or is there a documentation on what externals and libraries the patch is using ?

The important ones are pool from current CVS and prepend from Cyclone (not another one!). Except pool, which is too old there, every other external is in your Debian packages, like knob, plugin~, etc. So I see no special requirements.

You need to add all top level directories in the archive to your path, so all abstractions get found.

As jack has higher priority these things should not happen. e.g. you should get xruns, but no hangs. neither of pd nor jack. do they both just stop, or are there any messages ?

There are sometimes strange things happening. For example today Pd's patch display was messed up after I switched virtual desktops to provoke the hanging. Well, thinking about it, it might be the virtual desktop switching, that is soo bad. (I do this a lot and it isn't problematic with ALSA/OSS out.) Just now I tried to reproduce it. The patch was running okay for some time, albeit a bit shakey in tempo, but as soon as I switched desktops and back, I got this in the Pd console:

bad option "creapdtk_pd_dio": must be addtag, bbox, bind, canvasx, canvasy, cget, configure, coords, create, dchars, delete, dtag, find, focus, gettags, icursor, index, insert, itemcget, itemconfigure, lower, move, postscript, raise, scale, scan, select, type, xview, or yview watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd...

This doesn't look like a Jack error... Pd running is 0.37-test3 almost official.

Jack at that time reported:

subgraph starting at pure_data_0 timed out (subgraph_wait_fd=12, status = -1086326264, state = Running) client pure_data_0 error: awake_at = 143930029981 state = 2 timed_out = 0

**** alsa_pcm: xrun of at least 11.342 msecs

which looks not unusual.

I'll surely have to and will do some more testing of the Pd realtime/Jack combination. I normally don't use it much because of a perceived instability here and I don't really "need" Jack.

ciao

Frank Barknecht _ ______footils.org__

hi,

looking at the sources (do not use jack right now), I guess it is the sys_log_error() call in jack callback proc, that is directly responsible for corrupting things at the pd side.

Looks like the callback kicks in, before the main thread finishes sending a tcl command (still busy sending coords data for an array, etc.). The sys_log_error() itself sends "pdtk_pd_dio 1\n", which gets stuffed in the middle of a command.

No proof of this being the case, just thought it fits the pattern people keep complaining about.

Btw, there is another spot, where handling of the stream of gui messages sent up to the pd-gui is not very robust. This one is at the pd-gui side. In some cases (I get errors with audio on, when there is a SaveAs dialog open) the tcl notifier invokes the pd_readsocket() callback from another thread. Since the pd_tkbuf buffer is static, it is bound to become corrupt sooner or later.

So, how about making pd_readsocket() thread-safe?

Krzysztof

guenter geiger wrote: ...

...

bad option "creapdtk_pd_dio": must be addtag, bbox, bind, canvasx, canvasy, cget, configure, coords, create, dchars, delete, dtag, find, focus, gettags, icursor, index, insert, itemcget, itemconfigure, lower, move, postscript, raise, scale, scan, select, type, xview, or yview watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd...

This doesn't look like a Jack error... Pd running is 0.37-test3 almost official.

No, but its very strange. Looks like something has gotten pretty messed up. Some memory hole probably.

Frank

I agree with you about the sense of community etc. And i hate to sound like a whiner as i really am NOT the developer that alot of the folks on the list are. I tend towards sounding like i am always pissing and moaning about what doesn't work, but i really appreciate all that you folks on this list do. But to be honest i have tried using several of pbd's code over the years, starting with Quasimodo, and i drooled waiting, but never ever got it working right. The same with ardour, it never ever builds for the normal shmoe (ie ME) who wants to experiment. So there is your other fragmentation with audio softwares...artists want tools that work...sometimes right away. These problems with jack i am sure will get fixed but they are too reminiscent of past history.

Soundflower already works with pd. Bam. done.

On Monday, January 19, 2004, at 12:33 PM, Frank Barknecht wrote:

Hallo, Adam Lindsay hat gesagt: // Adam Lindsay wrote:

...

Frank Barknecht said this at Mon, 19 Jan 2004 17:56:40 +0100:

...

But doesn't Soundflower do anything else than the Jack Tools from http://www.jackosx.com/ ? Pd should be able to work out of the box with the CoreAudio-Jack wrapper included in the Jack Tools, or doesn't it?

To be honest, I don't know. I was very interested when I heard about Jack Tools being released, but it's not very clear on what it does and how it does it. I've just installed it now (need to restart to test).

The soundflower download is considerably smaller, so I have faith in it as a small, light shim, and I got it going with minimal effort. More choice can't hurt!

Well, as a Linux user, of course I am biased. I don't think, that fragmentation in this area (sound output, routing between apps) will benefit the general cause: more interoperability. I wished, that Cycling and Matt would have put their efforts into making Jack run on OS-X, instead of writing another software that basically does the same, but is not as powerful (yet, maybe). I see Jack as one major achievement of the Linux audio scene, that deserves more widespread use in applications (although I still cannot use it very well with Pd...)

ciao

Frank Barknecht _ ______footils.org__

---

PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list

Patrick Pagano,B.S. M.F.A candidate http://www.digitalworlds.ufl.edu http://www.screwmusicforever.com/SHREESWIFT

Hi all,

Jacktools Os X work fine for me with SuperCollider, Max/MSP an PD, It's a great tool!! At this time is more flexible than Soundflower. I have more things to say but in spanish...

Jose

Quoting Frank Barknecht fbar@footils.org:

Hallo,

Patrick Pagano hat gesagt: // Patrick Pagano wrote:

...

Soundflower already works with pd. Bam. done.

Yeah, but: Max works, Pd has problems. Bam, done, too?

Not done for me. Pd runs on Linux and Irix, Max doesn't. Bam! Jack runs on Linux, Soundflower doesn't. Bam! I even have to use non-open-source software just to unpack Soundflower. Bam! Soundflower might work better on OS-X currently (cannot confirm) but it has much less features, and I'm curious if it could grow to support everything that Jack supports already *now*. Jack even has a license.

(This isn't meant too serious. Feel free to use whatever suits you.)

ciao

Frank Barknecht _ ______footils.org__

---

PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list

Hallo, Adam Lindsay hat gesagt: // Adam Lindsay wrote:

That's what pleased me the most. Instant gratification. (I've since tried Jack Tools, and ran into the same problems others on the list have. Jack is clearly more powerful--it just doesn't work.)

That surely is the goal of Jack, too. I just see not much sense in splitting the efforts here.

There was a bit of work to be done to get Pd closer to the "Bam" usability point on the Mac, but that was fun in a sense. Hacking makefiles and twiddling code is interesting to a point (closer to user- space for me, personally), but needing to hack at every level (down to audio drivers) becomes a bit tiresome for some, and is simply beyond others' abilities.

True, true. This also appies to us from the "support team" here and especially to the leader of the pack: if there are manymany sound-APIs to support, things get more and more complicated. That's the main selling point of Jack: It's (or intends to be) the high-end for both OS-X and Linux. I'd wish, for Windows, too, but that seems to be quite hard to achieve.

Incidentally, when Jack Tools gets going more easily on MacOSX, looks like Soundflower will be compatible with it in that it provides another virtual device, and so more complex routings could be achieved between the two. (e.g. iTunes -jack-> SC3 -soundflower-> Pd -> dac)

You wouldn't need Soundflower for that, if Jack gets rid of the remaining hassles. Jack was designed to allow any number of applications to create any number of connections bettween them. Personally I don't even use it that much, as I work almost exclusivly in Pd. But I've seen wild setups with alsaplayer's output going to Pd and from there to freqtweak while Ardour was recording and the audience listening.

These things are far out.

ciao

Frank Barknecht _ ______footils.org__