Speeding up [phasor~] made no difference whatsoever.

I have few versions of PD on my computer. The one I'm using right now is 43.4 extended.

I tried entering batch mode in two different ways. First, I tried entering and saving it as a startup flag through preferences. Then, after that failed to produce any results, I tried entering -batch in the console. Apparently, neither attempt worked, because the GUI remained intact in both cases.

I need to be able to see my patch, so batch mode does not sound appealing.

I'm not aware of any control domain replacement for [vd~]. Perhaps you or someone else could point me in the right direction.

Like I said, I'm trying to pitch shift a sample from one array and save it to a second array, both without delay.

Okay, I think I may have managed to start the patch up in batch mode. But doing so broke nearly every object, turning them all into boxes with red outlines.

Running Puredata with the -batch flag doesn't appear to have done anything whatsoever to speed up the playback of tabread4~.

EDIT: Actually, the problem might be that Puredata is refusing to save my startup preferences. How can I fix this?

I'm trying to figure out how to perform a pitch shift on an array and get the results to another array in as instantaneous a fashion as possible. What I don't want to do is play through the input array in real time, which means that that the objects and patches included in Puredata that are designed to perform pitch shifts are largely useless to me. They play through the file too slowly. As I understand it, one way to accomplish what I'm trying to do is 1) do a FFT, 2) shift the frequencies in the resulting array by a factor, and 3) do an IFFT on the resulting array. What I'm struggling with is the second step. Attempting to reposition the spectrum results in some frequencies landing in positions between bins, because, when calculating the shift in frequencies, I'm multiplying by a decimal rather than a whole number. If someone could tell me how to shift the pitch of a sample and get the result to an array it would be greatly appreciated.

Thank you for your reply. In fact, the table sizes are correct. The problem is that it takes minutes for it to calculate the cross correlation. So I'm wondering if there's some other, faster way to do it.

I figured out that the problem arises when the tables exceed a certain size. The tables I was trying to correlate were rather large. So my question now is: is there some other way to efficiently perform a correlation between a pair of large tables, meaning tables with 400000 and 800000 indexes? Ideally, I would like to perform as many correlations per second as possible. I'm not sure if that's really going to be computationally feasible, though, unless I greatly reduce the size of the tables. Some help would be appreciated.

Actually, I just realized it isn't working in the other patch, either. So basically, how do I make it work? It works in the help patch, but appears to do nothing outside of it.

For some reason I can't use iem_tab's cross correlation object in one particular patch--it is completely unresponsive. This is in spite of the fact that the patch in question is almost identical to another patch in which cross correlation works. The one change concerning iem_tab is that a different set of tables are being used. The tables in question are the same sizes in the same order as the ones in the working patch and they are populated, so it makes no sense to me whatsoever.

So all I have to to do is open the patch in a text editor and paste those codes into the right spots? That will work excellently. Thank you for coming up with that solution. (I just wish there was an easy way to format the text. As it is, I have to insert a semicolon when a line ends and hope that I've positioned it in a way that avoids the appearance of lines ending at different horizontal positions.)

Here is a file illustrating my situation: Untitled-1.pd As you can see, the comma gets a slash added to it when it arrives at the canvas as a label.

The text doesn't need to have anything done to it once it arrives at the canvas or whatever object is capable of displaying it. The only thing it needs to be able to do is display a different block of text when prompted to do so.

The method you showed me in "please.pd" does allow me to embed commas inside messages, which is a step up, but semicolons cause line breaks to occur where I don't want them. Also, I need to be able to send the text to a canvas. When I try to do that, the commas and semicolons get interpreted when I don't want them to be.

All I'm trying to do is send a block of natural language text from one location to another where it can be read intact. Surely there is some way to do it.

Thank you for replying.

I'm using PD Extended.

I did find a partial solution to the comma problem. I discovered that [makefilename %c] will produce a comma when fed the number 44, and that this comma can find its way to a canvas object via [zexy/listtosymbol]. However, a "/" is always added to the comma if I send it with other text in the message. I'm not sure if there is a way to get rid of the slash or not. Hopefully there is.

There is really nothing to show, as far as the patch goes. A message box connected to a canvas, correctly transferring everything to its label except commas, line breaks, and semicolons, is the only informative thing you'd see..

I'm working on a project that requires me to be able to freely copy text within a patch from one location to another, but I've run into a couple of problems. One of them is that PD doesn't allow me to transfer semicolons or commas between windows; it treats them as special characters. The second problem is that PD doesn't seem to be able to transfer line breaks from one chunk of text to another. Any help with getting around these two problems would be greatly appreciated.

My operating system is Windows Vista, and I use Pd extended, version 43.4.

No, I wasn't using any messaging to PD.

Anyway, I ended up having to rework quite a few of my ideas for the project, so in the end, this didn't cause me to lose a whole lot of work. I'm taking extra care now with save files; I back them up in a different folder, and check to make sure that PD isn't producing any 1KB files when it shouldn't be.

I've been working all day on a pair of patches, and I've been saving their contents regularly. Several minutes ago, PD crashed. When I reopened the only patch that was open when PD crashed, almost everything had been deleted, including things that were in the patch before I even opened PD today. I then opened the second patch, which was an earlier version of the one I had open when PD crashed, and that too had been almost completely cleared out. I tried opening these two patches in a text editor, and found that almost all of the data was missing--the text files had been whittled down to 1-point-something KB in size. So what I'm wondering is what happened, is there some way to recover my work, and how can I avoid this happening in the future (if PD just does this kind of thing at random, I may have to stop using it, because I can't risk losing saved files with lots of time and effort behind them)?

@ingox

I tried the second, simpler setup, and so far, all of its output is what I was I trying to get. So it looks like you found a solution. Thank you.

Thank you for posting in my topic.

The setup that you posted is unfortunately not one that I can use, because the [==] and the spigot's left inlet are supposed to receive two different numbers.

I would probably post the patch, but it looks like the work of a tornado, so I don't think anyone would want to try making sense of it. I guess I'll post it anyway. The problem appears to be located in [pd all match]. The patch is triggered by its user pressing the topmost bang on the main page.

I have a very simple spigot mechanism in place. To the right inlet an [==] object is connected. It sends out a 1 when it receives a 3, and otherwise a 0. To the left input of the spigot is connected a number box that receives input every time the [==] is triggered. The problem is that the spigot refuses to work correctly when the patch is running. It keeps letting numbers through when [==] is outputting a 0. The only thing I can think of that might be the problem is that [==] and the number box are receiving their inputs at different times, so that the spigot is sometimes open for a number when it should be closed. However, I went to fairly ridiculous lengths to ensure that the two inputs are arriving at the same moment, even though it shouldn't have been necessary. And yes, the number box was connected to the spigot after [==]. I checked multiple times. So what on earth is the problem?

As far as I know, [+ ] and [/ ] store both of their last inputs rather than the last solution they came up with, so that shouldn't be a problem unless the hot inlet is receiving its number before the cold inlet.

It should be mentioned that the middle inlet of the [list split] empties itself into the hot inlet of the math object. Apparently [list split]'s output is released in sequence from left to right, so that by the time it releases the rightmost number, the math object has already been banged. Essentially, it's ignoring the order of operations I specified by connecting the cold inlet first. I'm not sure if this is abnormal behavior or not, but it's frustrating and pointlessly limiting. I strongly suspect that other problem spots are variations on this. I have some subpatches with multiple inlets receiving numbers, and it seems likely that these numbers, which arrive simultaneously, are trickling through the subpatch's inlets one by one, in order from left to right, and in so doing not only ignoring the order in which I connected them to subsequent objects but rendering their motions non-simultaneous.

@gsagostinho: The example you gave works for me. I think the problem only happens when the numbers are arriving from the same source (apparently the use of multiple [inlet]s makes all of the them function as if they're sticking out from the end of one object).