who is responsible for this object? these features should go to the help
patches
João Pais
And just in case someone on the list hasn't seen this,
http://crca.ucsd.edu/~syadegar/expr.html
gives documentation for the expr expr~ fexpr~ objects. Table
functions (including size(), sum(),
Hi,
going back to the subject of the long loading time of patches: before I
suspected that it was due (besides some difference in the newer version)
to several nested gops. that's not the case, as after switching off the
gops it still takes as long (or maybe slightly less, but still too
Hi List, Hi Georg
I would like to have one subject discussed...
I am encountering a problem (OS X Mac-Intel - Pd-extended version
0.40.3-extended-20080614)
When quite a big patch i am working on (CPU-load around 80-90%) i
actually can not close it in a clean way.
Sometimes i slightly
Use a different package, like Debian/testing or Ubuntu/Hardy. Or
build it yourself.
.hc
On Jun 22, 2008, at 2:56 AM, Rich E wrote:
In an ongoing attempt to find the root of my audio problems when
using a firewire soundcard with jack/freebob, I just installed the
latest stable version
Thanks Andy, what do you mean with not very long?
I am working with 4 channels, so I chose writesf~ + soundfiler +
tabread4~ and everything is working fine.
_Ricardo
2008/6/18 Andy Farnell [EMAIL PROTECTED]:
Hi Ricardo,
Provided the file is not very long you can read it into an array
Edit the existing help patch and add this stuff, then add it to the
patch tracker, and it should be included. At least, I'd include it
in Pd-extended.
.hc
On Jun 22, 2008, at 12:06 PM, João Pais wrote:
who is responsible for this object? these features should go to the
help
patches
There is a bug in the prefs loading of Pd in general where it'll peg
the CPU while loading for a bit unless you specify npath and
nloadlib. Perhaps it is related to that?
Right now would be a good time to download and try a nightly build.
AFAIK, there aren't any outstanding bugs. I just
did you post the patch somehwere? I think several people mentioned that
pdx got slower, would like to know why, too?
marius.
João Pais wrote:
Hi,
going back to the subject of the long loading time of patches: before I
suspected that it was due (besides some difference in the newer
By the way, this should be fixed to make more sense in the latest
builds:
- default saveas folder is PWD on GNU/Linux and Windows
- default saveas folder is Home folder (~/) on Mac OSX
- new patches default to the folder last saved in
.hc
On Jun 10, 2008, at 7:02 PM, Vincent Rioux wrote:
Congrats on the release! Just curious if integration with common Pd
build system (aka Pd-extended, I suppose) is on the roadmap still.
It would be good if we can combine efforts on this one to save us all
time and unfun work.
.hc
On Jun 15, 2008, at 9:11 PM, [EMAIL PROTECTED] wrote:
On Sun, 22 Jun 2008 09:06:12 -0500
Ricardo Dueñas Parada [EMAIL PROTECTED] wrote:
Thanks Andy, what do you mean with not very long?
You might find that files over about 2 mins will play back
with poor quality on a 32 bit machine.
I am working with 4 channels, so I chose writesf~ +
I built pd-extended from svn. I just don't understand why this is necessary
in my case. I thought it wouldn't matter if my library is newer, but
compatible, than the one the binary packages were compiled with.
On Sun, Jun 22, 2008 at 5:30 AM, Hans-Christoph Steiner [EMAIL PROTECTED]
wrote:
compatible is the key word there. As the error message says,
client linked with incompatible libjack version
.hc
On Jun 22, 2008, at 8:14 PM, Rich E wrote:
I built pd-extended from svn. I just don't understand why this is
necessary in my case. I thought it wouldn't matter if my
For this release, there has been a lot of work in making the GUI and
user experience much more fluid and easy. There is a new visual look
that was designed to make patches more readable. Additionally, lots
of things have been tweaked to make Pd behave more like a normal app.
There has
I'm sorry to be replying so late to this, but I was away for a week.
The first argument to [polywavesynth] is a tag which is prepended to all
sssad-saved settings for that instance. For example,
An instance created with [polywavesynth wav1 32 1] will, when sssad-save
is called, save a list
Hurrah, great work Hans... Pd is starting to feel quite native on the Mac.
The app-generator is fantastic. I've got quite a few patches designed
for just such a thing.
- the GUI runs slower on some older Macs
It's definitely not just older Macs! I've got a two month old Mac Pro
2.8x8 that
So it's not just XP then. It makes it hard to even build a patch, because
I'm afraid of using GOP.
Start-up of the program itself is no issue. The slow-down occurs whenever I
open my main working patch. It took about 30-45 sec before (last released
pd-extended package). Now it takes 5 1/2
I realized that soundfiler truncate the file to 400 elements.
Is there a way to load a file into an array, withuot this restriction?
What I'm trying to do is:
1. record the file with [writesf~] (this file could be long, about 5 or 7
minutes)
2. finish the recording
3. load it into an array,
Hans, thank you for doing that.
I have some remarks though:
Am 2008-06-23 um 06:58 schrieb Hans-Christoph Steiner:
- default locations for user-installed externals, helpfiles, etc.
Mac OS X: /Library/Pd and ~/Library/Pd
i still think it should rather be /Library/Application Support/Pd
-
On Mon, 16 Jun 2008, Andy Farnell wrote:
with [tabread4~] being good enough for playing back files at
their original rate,
If you are going to playback at original rate, [tabread4] is both useless
and 10 times slower than [tabread]. All that [tabread4] is good at, is
playing back at
Yes that'right, hmm I guess I knew that but said it in a woolly way
Amend that to
[tabread~] - play back at exactly the original rate
[tabread4~] - play back at close to the orginal rate
[tabread4c~] - play back with wider transposition
On Mon, 23 Jun 2008 00:50:44 -0400 (EDT)
Mathieu
21 matches
Mail list logo
