That did the trick. Does it just revert the settings back to 'factory' settings? I never changed the values in the window since I never could. So the settings it reverts back to is what it already was set to. Either ways, thank you very, very much.
I've run into an odd issue. I recently started using Pd vanilla (0.47-1 on OSX El Capitan) instead of Pd-extended.
I've found that if I open the 'audio settings' window found under the 'media' tab, I can't for the life of me close it again, no matter what I do.
At first I thought it was because I changed the settings to something PD wouldn't accept, but I've found that I just have to open the window, even if I don't do anything, I still can't close it. The window itself is not frozen, it's just unresponsive. Pressing 'x' in the window does nothing, pressing 'cancel' or 'ok' does nothing.
When the window is open I can't do anything on the open patch. I can navigate the menus and turn dsp on and off in the console, but pressing anything in the menus does nothing. I've tried to set the console to show all messages, but there is nothing to show, no useful error messages or anything alike.
The only thing I can do is force quit the application and open it again.
It isn't connected to any audio interface at this point, just the Macbook's built-in outputs. I haven't had it set up to any external interface since I made the jump to vanilla.
Has anyone run into this before?
Thank you in advance.
Yours are the exact instructions I tried to follow a few days ago.
As of now, I'm still a whole lot wiser. As far as I've understood, libraries that are contained in a single file are to be added to the "startup" for load at start-up. Libraries consisting of a folder with multiple, separate files should be added to "path".
First off, the Deken manager downloads the libraries to a folder called "extra", not "pd-externals" or something similar. I've got no folder called that. I couldn't access the folder through the "choose folder"-prompt, since I have to access the contents of the Pure Data application, so I had to create a desktop shortcut to which I could easily choose the "extra"-folder when adding paths to "path".
This is what I am greeted with on start-up.
And it just keeps going all the way down. It seems to go through the contents of the libraries, but gives me a failed message. I now see that it looks for the contents of the zexy library in the folder of cyclone and tries to look for the files in neighbouring folders. Why would it do that?
But, say I call up an object I know only exists in an external library, say, cyclone's [cycle~] object, I will get this:
The first few lines show that it's trying to look for the library contents in my main folder (users/marc). I can't see why it would try that. It then tries the paths, fails, but then succeeds.
This is what my "startup" and "path" folders look like, respectively:
And the contents of the "extra" folder:
Thank you, in advance.
I migrated from Pd Extended to Vanilla (0.47-1) a few days ago. I've tried to familiarize myself with the handling of externals and the Deken manager, which seems to slowly become more understandable the more I work with it.
But today I've run into some odd issues I never experienced with Pd-extended.
– First of all, the console is a mess of "tried to load, failed" and "tried to load, succeeded" at every start up, which is understandable, but I can't seem to figure out what to take from it. Sometimes I get both the "failed" and "succeeded" version of a message one after the other, regarding the same library/external. Sometimes it will claim to have failed trying to load a given external, but I can call up the objects just fine without having to [declare] or use the [name/*object] initialization.
I would assume that I have made too much of a mess trying to add the paths to "path" and "start up". So I guess it's trying to look for certain things in subfolders where it's not? The issue is that everything seems to load up correctly, but I still get a ton of misleading console messages.
– This one is odd. After having loaded up Pd and scrolling up through the console's many, many messages, I will get to the "credits" message of the zexy external, but it will lag and freeze for a moment before reaching it, sometimes multiple times before allowing me to scroll by it smoothly.
– I tried to continue work on a patch, a 4 channel random sample player. The gui elements will sometimes freeze after pressing play and running everything, which renders all gui elements unresponsive, though I can still operate the patch, but just with no update. From here on out I can't close any patches or windows, nor can I go into patch mode, I simply have to close down Pd and open it again.
I understand that many gui elements can be taxing, but I really haven't got a lot of them going on. I have worked on patches far more graphically taxing in Pd-extended without any problems what so ever. In fact, I've never had any issues like this with Pd-extended.
There is some [metro] objects banging at 100 ms intervals to update the 4 individual audio arrays, but stopping those didn't seem to help a whole lot.
Everytime a sample has ended, it will bang and choose a new sample for immediate playback, sometimes the whole patch system seemed to stop, seemingly as if not being able to handle the stream of information. Again, no issues in Pd-extended.
I hope you'll be willing to help me out here. I suspect that the first order of business is to clean up the "path" and "startup" menus to clear up the system, but I'm unsure about how I would go about that.
I got it to work with [msgfile] after some fiddling. I found the helpfile on the object a bit confusing. But was able to send the number to [msgfile] via a [goto $1] message, which - annoyingly - doesn't output anything by itself before a bang is received. A simple use of [trigger] to direct the flow of bangs sorted it out.
Using a simple textfile to address the filenames doesn't seem to get any more convenient. Thank you, weightless.
Hello. I'm trying to create a sample-player that plays random files from within the folder of the patch.
Right now it's composed of a [random] object sending out values between, say, 0 and 10 to a [select] object that then routes the bang to a message containing the specific filename, which is sent to an [open $1.wav] message for [readsf~], which is then read. No problem, it works just fine.
But as the patch grows and the number of samples I want to use increases, I want to be able to swap out filenames faster and with more ease, and typing in the individual filenames of each file quickly becomes a hassle. A workaround I did was to simply re-name the local samples to the values 0 through 10, so that I could skip the use of the [select]-object altogether, but having to re-name samples every time I want to use it in the patch is likewise a hassle.
Is there a way to create an index of symbols (for filenames) that can be used in a similar fashion to [table] and [tabread]? Input a number, it spits out the information sitting in the relevant index. Would [list] be a way to achieve this? I haven't worked too much with the object, but from what I gathered, it didn't seem to be the best choice. But please do enlighten me if I'm wrong.
I'm using Pd-extended for what it's worth.
@wale-av, the idea is not to have the text editor itself create the qlist-relevant text file that will contain the time marks and what not, but rather to allow the writer to type in, say, Microsoft Word, whilst the keystrokes are also being logged by a separate application, i.e a PD patch. The actual file and subsequent buffer that the text editor uses should be of no importance, is that is not used for anything, but it's rather a matter of convenience for the writer to be able to write as they would otherwise while it logs the text, if i.e the text which is to be used as a qlist-score is a journal entry. The chosen text editor would, so to speak, only be a convenient "front-end" for the task.
Is it really not possible to do this? A sort of send-application, that inputs both the text in the given text editor and another program simultaneously? To split the keyboard input to be active in multiple applications? I know this would create the possibility of mixing up shortcut commands and alike, but since the keys used by the writer should only be what's usually used in writing (no alt/ctrl/cmd + anything), I think it's possible to avoid.
I think I'll be able to write a PD patch that logs every keystroke, as its given (reference?) number in a textfile with a time mark, by using the
moocowexternals not found in PD-Extended? I can't seem to find them.