@LiamG it is an object from listabs that stacks lists from values it recieves.

BOOM! Finally found the culprit. It was a [list cat] object that wasn't getting properly cleared. @beepbeep - you da man! Now my patch is finally performance ready. Im stoked.

PS: I should also mention that you will not get any output at all until there are settings set in coll object which holds the global settings. Each note that can be played on the keyboard into the first midi input will recall a list of settings which are stored for that key. For example, C1 on the keyboard will trigger an A diminished chord in third inversion, open position and a lydian scale for the mapped input etc. If the coll object which stores those settings is empty for that key, nothing will happen, so you'll initially need to enter a key and then set some settings on the patch's UI. Best thing to do is set every setting on one key and then use the copy paste function that I built in to set those settings for every key just to get the thing initialized. Then you can set each key to your liking. Soon I will implement a default setting that will fix this issue, but as I said, Lifes been all naggy lately... so if you go to use it and it doesn't seem to work, just keep this in mind. Also, I admit that not everything is well labeled yet... For now Im the only one whos used it and i know where stuff is... for instance the little ulabeled button next to the button labeled "seq" will toggle the sequencer window on and off, and the number objects with the green buttons on the right hand side with no labeling are to control the osc inputs and outputs - ie setting the ip address etc. With the toggle button marked flam turned on, you can click drag an array where the display screen looking tghing is to set different flam timings of how the chord plays.. I tried to make it feel and function like your usual VST plugin.... just toy with stuff and you'll figure it out... And finally, the guts of the patch can be found by dragging the top level window size bigger to the right until you see the subpatch boxes... ok, Cheers

Hey all. Sorry for the delayed response here. Thank you all for the replies.
@beepbeep - You know what - your idea of what is happening is damn likely. There is a lot of list fifo and lifo going on in the the later stages of the patch, and a ton of things like notes being stored as lists for later use etc. It also has a lot of chords being triggered from single note input, so note-off messages ending up where they are supposed to is something that has been one of the major challenges of the building the patch from the beginning. I finally managed to get noteoff messages to happen in a reasonably reliable manner, but now and then there will be some stuck notes, which I dealt with in a way that is a bit quick and dirty, and not exactly elegant... I have been so so busy with boring life crap that I have not been working on my patch for a while... but reading your response gave me some inspiration in the form of a likely lead on how to fix the problem. I am going to look into it a bit later today and see what I can find. For the rest of you, here is the patch in question... I was hesitant to let it out because I always sort of considered it one of my secret weapons in the studio... but hell, I may as well share it with my most favoritest music community with hopes that you all enjoy using it as well as maybe pinpoint the bug in question. You will need classic pd-l2ork to get it working. I made a version in purr-data, but for whatever reason it was always unstable and the latest versions of purr-data crash on loading every time... so I will probly have to start it from the ground up when I am finally ready to update it... that said it works quite well in classic l2ork, save the problem stated in the OP. Please, Id love to know what anyone who checks it out thinks or if they find the problem before i do... Move the folder from the attached zip fileCM.zip into your path and open the top level patch, CM7.pd located in the CM folder Also note that there are two midi channels which can receive midi. the first channel triggers the chord memorizer, the second recieves notes , remaps them based on the chord which was triggered and the options selected respectively, and outputs them from the second output. Any questions about it are welcome. Cheers!

I like to think i am pretty savvy when it comes to PD, but alas, I still have much to learn it would seem, as I cannot for the life of me solve an issue with a patch of mine that has been driving me mad for quitge some time now. When I open the patch, all midi runs fine. Everything is low latency and very usable... but the more I play around in the patch and play keys and alter settings, things get slower and slower... until finally after a while there is too much latency in the midi system to even use my patch properly. The problem is solved when I shut down PD and restart the patch, but then rears it's ugly head once againm after some time. The patch is prety complex andf has a lot fo stuff going on, but it is a midi only program. The audio engine is off, so that is not likely the cause. Im thinking it has something to do with the console stacking up, or various objects which store data stacking up and bogging down. I would like to build in some way to clear things up soo the latency never piles on too much, but I cannot figure out which object is causing it or why! Does anyone know of any onjects that are known to cause this problem so as to point me in the right direction? I can post the patch if anyone cares to see it, but I warn you that it is pretty huge and would have layers and layers of patching to dig through. Maybe there is some way to globally clear all the midi data buffers or something? any help would be immensly appreciated, as the patch otherwise works well and It's something I use in almost every session!

Many thanks.
Cheers!

sometimes permissions with things gets a little wacky. You might try editing your visudo file to give the pi user more access. Also make sure the target port is not in use by some other process. Finally, in some cases I have managed to get things like this to work by force claiming ownership/access to a file using one of the two following methods:

sudo chown <username> <file name> (Claim ownership of a file)
sudo chmod 777 <filename> (assign read/write permissions for all users to a file)

Hope that helps

I run into this problem quite a bit, as i demand puredata on every freakin machine I own. There are a couple ways around it. Some hackier than others.

For one, in ubuntu and debian based distros, you can force install it with

sudo dpkg -i path/to/pdl2ork,deb

This will install it, but then throws an error message saying theres a dependency problem. It will run fine, but any time you go to do anything with apt from there out, it will make you remove pd-l2ork before allowing for any changes in your packages.

In this particular instnce, libglsl2 refers to the linux scientific library, which is actually present in ubuntu repositories, but under a different name. That means that pd will work fine, but apt will complain. The hacky way that I got around this was as follow. I extracted the pd-l2ork.deb file and altered the dependency list in the control file to exclude that package. that can be done using this walkthrough: https://ubuntuforums.org/showthread.php?t=110458

Run those steps and remove libglsl2 from the dependency list and the output .deb file will install with no errors and run just fine. (from my experience this works, but as it goes with all hacky solutions, use at your own risk!)

The more conventional but potentially headachey way to do it would be to build/compile your own version from source and run it from within the source folder without installing it. I have used this way plenty, but it's ultimately a lot more work to set up, and also you usually will have to set up your config file to point to all of your extensions manually. This way bypasses messing with apt and dpkg entirely, making it safer but unless your a wiz at compiling stuff, clear your day for this project.

the [v] object allows for the creation and recollection of global variables. You would use it by calling the object and giving it a name. ie: [v foo]. Now, any time you create an instance of [v foo]. you can send it numbers to set it's value globally, or send a bang to recall it's value locally. If you need to create variables which have symbols or other kinds of data for it's value, then this can be accomplished in several ways. I tend to use cyclone/coll for this. Coll objects can hold a text file that acts as a list of variables and values which can be set and recalled dynamically. A named coll object will also become global in it's scope. Theres a few other ways to do this as well, but this is my goto.

I think the pvar object is like V object only it operates only on a local scope. hope that helps

@whale-av Damn, son! That sounds like one meaty ass project! Your idea does not seem flawed to me, however that whole setup x88 is going to be a really intense build! (you know that already though, i'd bet.) One thing I find is helpful when working with gear that eats electricity like it's going extinct is to add a large battery to the mix. What I mean, is hook up your power supply so that it has a powerful battery helping the power along with your wall plug. After so long, the battery will exhaust itself and you'll be back to similar problems, but that will at least give it quite a bit of run time with easier amperage draw. When it wears out, turn it off, give it some time to recharge and then your up and running again. Ample amperage will help improve your hot solenoid problem as well as charge capacitors a bit faster. It's not a fix-all solution, but in a project like this one, every little bit helps i'd imagine.
Cheers.

@pmh1d15 Most likely you need to add your user name to the dialout group in linux. The teensy registers as a modem if I am not mistaken, and also anything involving comports also requires you to access dialout permissions to function.

in a terminal window, type

sudo adduser <USER> dialout

where <USER> is your user name. log out, log in and you should be good to go.
Cheers

I'm not sure what kind of sound you are going for exactly, but if you plan to oscillate only one cycle of the waveform, you can expect it to come out sounding like an old buffered op-amp synth from the 80's. A cool sound, yes, but not entirely 'organic. use a larger portion or 'granule' if you will, to get it more natural sounding. Experiment with crossfading and looping the granule forwards and backwards in an alternating loop... sometimes that can help compensate for volume dips in elongating percussive instruments like a piano. Hope that helps

When you say "spin like an oscillator," do you mean you want the waveform of the piano sample to loop between transients to create an elongated note? This is certainly possible. I think what you are talking about is something like a wavetable synth. This could also be achieved using a sampler, setting the loop region of the waveform which you would want to 'oscillate.' The difficulty in achieving good sounding results is in finding a good point on the waveform that doesn't click, pop or drastically change volume between loops. This can often be remedied using crossfading, however, a realistic sound is unlikely to happen in this way, as looped samples which cycle only a few cycles of the waveform almost invariably come out sounding fake. To achieve truly realistic results, you will want to loop the largest possible portion of the waveform and probably use multisampling for varied velocity. Let me know if my answer is way off from your original meaning.

Having taken a quick look at your patch, I would say that my instinct agrees that the use if threshold~ is a likely culprit. The fact is that in the control realm, relying on pd to poll numbers fast enough to catch the 0.0001 decimal every time is a risky move. Even in the audio signal realm, such a task could be tricky when there are lots of notes being thrown at it. If you want to generate an ADSR with specific transients for each and trigger them with line~, I find the better way is to write the envelopes to a table with the last index of the table set to a value that will trigger the next set of parameters to the line object, until finally the release ends at zero. In other words, there would be a table for each, A, D, S and R. the last value of the table would always be set to some number that is outside of the range of your line~ that will get picked up by a sel or route object to trigger the next line until the release. When a noteon message is receiveed, it knocks your line of tables down like dominos. It does not rely on every tiny fractional decimal point value being polled, so its more likely to complete the sequence without getting stuck. Instead of sensing the signal for a tiny window, it simply reads off a precalculated list of values in order, and if it skips a few values for lack of speed, it will still end up at the next set of instructions. I hope I explained this well. I can do an example if you need. Outputing the tables to another line object can help smooth out choppy transitions if there are any. hope that helps.

pd extended offered this functionality as a built in feature from what I hear. Unfortunately, pd-extended is a bit dated and no longer maintained... that said, if your patch does not require features from the latest releases of puredata, you could build it in extended and use it's make-app function. If that won't work for you, then making a standalone app from a puredata patch is still possible, but not exactly a simple task. There are actually several ways that you could do this, all of which will likely require some knowledge of coding in other languages like C, java, python etc. If you were looking to make something for mobile devices, there are apps available that can wrap your patch to run in it's own app container type of thing in android and ios. For that, check out pddroidparty, libpd and mobmuplat. If you want to run a patch as a vst type plugin within a DAW, check out pdpulp, chamomile and the one that is i think windows only, pdvst.

If your only need to make a standalone app is to cater to people who are less computer savvy, then I would say that the amount of effort it would take to make a truly standalone app from a pd patch is probably overkill and then some. You could much more easily make a patch that functions somewhat like a standalone app, in that you click an icon and the patch opens up and runs, by creating a launch script. How you would go about doing this would depend on what OS you are using. OSX and linux both run on unix, so a bash script that launches pd and opens the patch with all the desired settings could be written, marked executable (sudo chmod +x <filename>) and assigned an icon. A script could even be made to automate the installation of puredata to go with it.

If you want to be really thorough, you could compile/build a version of puredata from source, making sure all the needed dependencies are contained within the source directory and linked accordingly, and house it in a bundled folder (something like all applications and .kext files on OSX operate,) But once again, this would have some caveats, has it's own learning curve and is generally no simple task for someone who isn't already well versed in these types of things. The easiest thing would probably be to just install pd for your clients manually or via script and make a launch script that they can just click on and have it automatically open pd and the patch of choice.

Hope that helps

an external that could help simplify a vocoder to a large degree would be fiddle~. If the sound you are getting from your patch is static or crackly, you might check your buffer size, adjust the amout of lookahead/latency and double check your audio settings, taking care to select an appropriate block size.

Making sure that the settings you are going for match your systems capabilities and stopping the dsp before making changes to audio settings tends to be good practice. Stray from that advice, and theres a chance things will work, but more likely to cause glitches and crashes.... from my experience at least...

glad to hear it. happy to help.

Does any command work in the [shell] object that you are using? If you run something simple, like 'ls' or 'pwd' will it output the file list of the directory? If so, then there could likely be a formating issue with the text that you are sending to the object. The way that puredata handles sending certain symbols and characters through messages can sometimes throw a command askew when translating to bash. To make things harder, the front slash that is typically used as an escape symbol to send symbols as literals is not allowed in messages within pd... So if the [shell] object is functional, but your particular command just doesn't seem to want to work properly, then you can try the following:

1 - make use of objects that convert text in messages to and from symbols, like [makesymbol] [cyclone/tosymbol] [cyclone/fromsymbol] [s2l] [l2s] etc.
2 - try sending commands to shell via [text] or [coll].
3- when all else fails, or a script is just too complex or uses many odd characters, open a code editor like kate (or textmate on mac,) and type the code in there. Try running it in a terminal to make sure it works. Save the file, and then in terminal run

sudo chmod +x "/path/to/file/filename" 

enter your password and now that file will be marked by the OS as executable. You can call it from the [shell] object by simply sending it the path to the file, or cd <path>; ./<filename>

If your script requires variables that change in pd, like $1 $2, then you can set that up in your script by defining variables and then sending those values as in separate messages. for example, in your code, you could start by defining a variable like

foo=0;

then in pd

[nbx]
|
[foo=$1(
|
[shell]

After you send the change in value to the variable, call the script again and it will output with the updated values.
In sticky situations in shell, this trick has saved the day for me many times. Hope that helps.

I have found that using sudo in shell is problematic. Ive thought of some ways to potentially work around this, but in honesty, haven't tested them yet. If you try any of these ideas, pleas let me know how they go. In theory, they should work.

1 - try the visudo command and set your username to have nopasswd privelages so that sudo commands do not ask for a password.
2 - enter the sudo command through shell like this: echo "<your password>" | sudo -S <your command>
3 - try constructing the command with fakeroot instead of sudo

Hope any of these helps

If jackx wont work for some reason, you can also acheive similar results sending jack scripts through the shell object