-
oid
And a simpler version, could be made more efficient on the reset side but I am not sure it is worth it. Not sure what I was thinking recreating moses with the swap/pack/route.
knob3.pd
Edit: went ahead and fixed the reset stuff, could still be made more efficient yet with a once between the bang of the [t f f b] and the [f ] but that is probably a meaningless improvement over the simpler [change]?Edit (again): But I suppose there is no reason to test floats after the test has passed so sticking a spigot before moses would be a worthwhile improvement. Updated.
-
oid
@dreamer said:
Larger might be possible, but I found that it's harder to hit the latching value as precision of the received value goes down and you may over-shoot.
You can just test if the number is larger or smaller than instead of equal to, a bit more complex and could be too much for the daisy but who knows, I know nothing about it.
knob2.pd
Edit: Suppose that bang should be triggered by the right float atom, forgot to switch that over, bang was mainly for easy reset while testing.
Edit: Actually it is not much heavier than the previous version, just a test which happens once to see if the number is larger or smaller then the previous and the route stuff. Have the right float atom go to the right inlet of the [f ], bang the [f ] and the reset bang once when this parameter is selected.
-
oid
@zigmhount said:
Pd with other MIDI clients from within the Pd patch.
I missed that, in that case I think I would just do it all in pd. Script to start pd instances so they are in known order (if needed) and then use [command] to get the port numbers and place them in suitably named [v ]s. Make your midi router a patch and then send your alsa commands out through [command].
-
oid
@zigmhount I generally just pay attention to the order I start them in and specify the midi stuff at startup,
pd -alsamidi -mididev 1 <files to open>
first listed by aconnect will be the first started. The entire startup process including connecting the midi ports can be scripted so all you have to do is run a script and have everything good to go. I will try and get around to making my pd script a more generic startup/connect script if you want, probably can do it tomorrow. But perhaps someone knows a way to name them or has a better alternative. I just went with what I know when I made my script, more interested in making it all work then figuring out the best way. -
oid
@ingox Did you have a question? You did post this in Technical Issues
Never knew append was implied if the arguments to [list] started with a float, feels like once a week I do [list symbol] and have to go back and add in "append." [text] used this way is much cleaner than any attempt I have made at anything beyond the simplest of recursion, still going to take pen and paper to figure this one out.
-
oid
@seb-harmonik.ar So "here" in
[send here]
is a symbol even though it was never in a [symbol] or [list]? The names in named objects are implicitly symbols? In[1 2 3 here(
here is a symbol and in the hash table because starting with a number makes that a list so "here" is a symbol but what about[this here(
is an any (is that the same as a text/comment?) so does not end up in the hash table? I have been hoping that idea for[pdcontrol]
to get the number of symbols in the hash table would happen so I could finally get a solid grasp on this.Edit: Also, do symbols ever get removed from the hash table? If I delete ever occurrence of a symbol does that mean it is no longer in the hash table? Do symbols get removed when the patch that created them is closed?
-
oid
@KMETE As far as pd is concerned a send and a receive is the same as a wire. The symbols used to name the send and receive may possibly cause things to slow down but you would need thousands of unique send and receives for that to be an issue and I am not sure if statically named send and receives actually have symbols which end up in the hash table. For all practical purposes, they are the same as wires and no faster or slower, but they can obscure the order of execution in surprising ways, especially when [value] is involved.
-
oid
@esaruoho I use a canvas on top of a [nbx], [nbx] gets from a [text] which has the info I want to display and is then applied as a label to the canvas, just click and drag like it is a numberbox.
lbt.pdThere is also https://forum.pdpatchrepo.info/topic/12960/a-drop-down-listbox-using-hsliders which is clever and works well despite some quirks but you get used to them fairly quickly.
-
oid
@Blindekinder said:
something like insert function (insert the block between two objects when dragging
Something like this?
Not sure what you mean by "when dragging." I have a whole complicated and massive macro abstraction that can insert large blocks and make all the needed connections and the macros themselves are just pd patches (most if not all abstractions are valid macros). It should be uploaded in the near future, slowly working on the documentation and there is one bug which makes it less then ideal for anyone who is not already comfortable and efficient in the vanilla interface since it does not work with redo (if you undo a macro and then redo it you end up with an empty object box instead of what that macro should have placed). But I have been using it heavily for about a year now and a real time saver. -
oid
@esaruoho Like this?
slowarray.pd
The time and frequency arrays output floats in the range of 0-1 which are shifted to the desired range, for time it is 1-60 minutes by the [*1000]->[*60] and for frequency it is 8.5hz-17hz, [*8.5] to shift the 0-1 output of line to span 8.5 hz and [+8.5] to get it to run from 8.5hz up to 17hz.Edit, error in the math for the time, should be {* 1000]->[* 60]->[* 60], first converts 0-1 to ms, second converts to seconds, third does minutes. lost a [* 60] somehow. Or you can just [* 3e+06] instead but I like to keep the math easy to read. Fixed the file but not the image.
-
oid
@esaruoho For a square wave you can just run a toggle into the right inlet of the [*~] and connect a metro to that toggle, everytime the metro bangs it will flip the toggle. Tabread needs to be read with [phasor~] or [line~] just like you do when you use it for a sampler.
-
oid
@seb-harmonik.ar You reminded me of a question I have wondered about but never quite could figure out from the source, all those pointers still confuse me. [text] and [list] allocate memory once their size exceeds 100, do they deallocate when they shrink? If my [list] has 200 items and I delete an item from it does it resize or stay at 200? Can I create a [text] or [list], dump 200 zeros into it and maintain the speed they have for under 100 while also getting the benefits their respective family of objects offers and [array] lacks? It seems sensible they would shrink as well since they could end up eating massive amounts of memory but [text] and [list] are not really designed to deal with large amounts of data like [array] but I don't really know.
Edit; I mean [list store] and not [list] since you can not delete from [list], just make another copy minus what ever which would mean reallocation. So no need to explain that unless I missed something here?
-
oid
@zigmhount said:
Also a good idea, I may give it a try. Although so far I've noticed dropouts when enabling synths in Ardour,
Isolating Ardour might work, depends on how reliant it is on that second core. You could try jalv which loads plugins as standalone jack clients, probably as low as it will get for resource usage if you want UI.
-
oid
@bonehead696 You need to add [declare -lib iemlib] to the patch. But I am pretty sure vanilla's [list tosymbol] does everything [iem_alisttosym] does so you can just replace the objects and skip the externals.
-
oid
@zigmhount I think in that setup I would not worry much about pd, its load will be tiny compared to a DAW (or most OSes) and that is where I would look for ways to knock CPU use down. Ecasound is a command line DAW which can be completely controlled from pd through various ways (going from memory [command]/[ggee/shell], OSC, UDP), uses much less CPU than the alternatives in my experience and combined with a minimal Slackware system kept me happily running on an old 4-core 1.8gig machine up until about 6 months ago when I decided to get a new computer on a whim.
One thing that can help (depending on your OS?) is isolate a core and run the DAW on that core, can keep the random dropouts from happening but it means everything you do in the DAW has to be doable with a single core. Works better when you have 4 or more cores since you can isolate a core (or two or more) for the none realtime stuff and let the system manage the other cores for the realtime stuff.
-
oid
@zigmhount Unless I was planning on running it on something with a single core I would use [text] since it makes it easier to separate the control stuff from the audio which allows you to stick all the control stuff in its own patch running in a separate instance of pd that does not need DSP enabled and communicate with the audio stuff running in another instance of pd through [netsend]/[netreceive]. I have made it habit to structure my patches with everything audio segregated out into an abstraction, if I start hitting the wall and getting dropouts I just replace the abstraction with a [netsend] and start up another instance of pd, takes about 5 seconds and problem solved.
-
oid
@bonehead696 zl is part of the cyclone library. If you are missing an object you can just go to 'find externals' under the help menu and search for the object, will generally bring up the library it is from. In this case the object is 'zl,' 'group' is an argument to 'zl' so you would just search for 'zl.' The space between zl and group tells you that it is an argument and not part of the object's name.
-
oid
@gazzyjuruj You need to install the externals required and then declare the symbols in the patch. To install externals go to menu help->find externals and search for the missing objects which will bring up a list of libraries which contain objects with that name, install them. Then add [declare] for that object, the [declare] helpfile will explain its use. This is a much better setup than the extended way of just trying to include all externals, more portable and the [declare]s means anyone who downloads the patch will know exactly what libraries you used so they do not need to hunt for them.