How can I actually see the routed list in a list box without using list store ?

If you look into the help file of the list box, you'll see that the list selector is always needed if the list starts with a symbol. So you need to convert whatever you wanna see to a list message, and the help file of [route] uses the [list] for that.

So, it should be obvious that you simply can't send a non list message to the list box. If you're asking how should it work without [list store], well, you can't, you need something. If you want an alternative to it, what is the problem with it? What else would you like and why? And if you expect somehow to send a non list message to list box, you simply can't and this is a very basic Pd thing, dealing with its data types. So use just use [list] or whatever...

As for the dollar sign thing, it's also another very basic Pd thing that concerns the management of selectors and data types, and it is treated throughout the documentation, one of which is the help file of [list].

So yeah, this is yet another request on my part to kindly insist yet once more, after many times, that you take your time to read the manual and help file of objects if you want to work with Pd. You've been using it for quite some time and you have too many questions that could be simply be answered if you took the time to read tutorials, the help files and the manual.

And simply don't expect Pd to be the same as MAX, they're different pieces of software (there's even a section in the manual that tells about their differences - it's section "2.11. Pd vs. MAX"). While you're at the manual, check "2.4.1. Message types (selectors) and numerical precision".

As for the help files, I told you to check the help file of all these involved objects, the list box, the [route] object, and the [list] object, which has a [pd about-lists] subpatch that should answer your question.

The help file of message boxes also talk about dollar expansion and has a section that explains all this in a subpatch called [pd dollar-variables].

The fist chapter of my Live Electronics Tutorial is "01-Pd.Quickstart" and gives you a good and quick overview, you should look into subsection "2.Syntax". This comes as part of PlugData, which you're using. I realized now that the 'control tutorial' does not have a good example about this, so I will add it. You should read that too anyway.

So yeah, I'm not really answering your question, but I'm telling you where you can find answers, and please understand my situation. I wrote a tutorial of my own, I revised and rewrote all the help files, I revised, wrote new sections and rewrote most of the Manual. I revised the tutorials, all in the hope that people would read them and find answers and not ask such basic questions over and over. And also so me or others wouldn't have to keep explaining the basics. Others can come in and teach you if they want to, but I'll just reinforce that you really should do that.

This is ok when someone just got here, is a newbie, and wants some guidance, like pointers to the documentation, but it's been a while you joined the community, and you're doing a lot of work, and you seem to resist and simply not do the basic homework. Personally, I feel this is abusing our desire to help others, but that's just me.

So please, just read the (blip) manual. And if you're still confused, if you haven't found what you need, if it's misleading somehow, I'd be more than glad to explain it to you and improve the documentation.

I'd love to hear from you things like "hey, I read this help file and I couldn't see something about xxxx", or, "I didn't find anything about message types in Pd, where can I read and check?". You know?

cheers

These are the contents of the .zip file you mention:

abs/                  CHANGES.txt                    examples/     LICENSE.txt  ofelia-object-help.lua  ofelia_textwindow.tcl   opencv_core4100.dll  opencv_features2d4100.dll  opencv_imgproc4100.dll    README.md
assimp-vc142-mt.dll  classesAndGlobalFunctions.txt  libxml2.dll  ofelia.dll   ofelia-object-help.pd   opencv_calib3d4100.dll  opencv_dnn4100.dll   opencv_flann4100.dll       opencv_objdetect4100.dll  stable-diffusion.dll

Are these supposed to be located in the ofeliaExtendedLib directory? Because, all there is in there, is already in the directory of the ofelia.pd_linux Pd external directory too.

@Zooquest You will hear clicks because there will be jumps between samples.... if the playback was at a sample level of 0 and you change the delay time to a point where the level is 1 then the click will be loud.
You will hear "steps" as the playback point is probably being changed repeatedly by the ctrl messages.

You could experiment with a [lop~] filter in the delayed sound output, with a high value e.g... [lop~ 5000] but you will lose some high frequencies in the echo.
That might sound natural though, like an old tape echo, but you will probably still hear the clicks a little.

Or you could "duck" the echoes by not changing the delay time immediately, reducing the echo volume to zero in say 3msecs using using [vline~] and not bringing the echo volume back up to 1 (in, say, 3msecs again) until you have NOT received a ctrl message to change the delay time...... for again 3msecs.
The last part of that would need a [delay 3] using the property that any new bang arriving at its inlet will cancel the previously scheduled bang.

You would need to duck the FB signal as well though, and all that that might sound worse than the [lop~].

I cannot remember well...... but this "sampler_1.pd" might contain elements useful to demonstrate "ducking" https://forum.pdpatchrepo.info/topic/13641/best-way-to-avoid-clicks-tabread4/12

Or do a crossfade between separate delays once the incoming control messages have stopped..... https://forum.pdpatchrepo.info/topic/12357/smooth-delay-line-change-without-artifacts ..... as you can then avoid the "duck"ing effect.
David.

@oid the stored list is freed every time a new one is supposed to be stored (or the object is deleted/freed). The 100 element lists are only used on the stack (non-stored lists). When lists are stored they are always stored on the heap.

e.g.

    /* set contents to a list */
static void alist_list(t_alist *x, t_symbol *s, int argc, t_atom *argv)
{
    alist_clear(x); // <-- clears stored list on the heap

the lists stored on the stack are only used when sending a temporary list to an outlet (like triggering [list append] from its left inlet)

now that I'm looking at it again I'm not sure why getting elements from lists should be slow if using [list store], if you know their indices. bc lists are actually contiguous memory (not linked lists).

edit: when lists are cleared or elements are deleted the memory is freed at that moment

edit2: [array] will probably be more efficient in the majority of compatible cases because memory is only allocated once when it's created, and deallocated once when it's deleted. (at least when there's a reasonable maximum size and it doesn't have to be resized)

How can I save a list that I have created with [openpanel 2] and [list store]?

[bng]
|
[openpanel 2]
|
[list store]

...I would like to store this output in the patch upon save.

If I edit the [list store] like this...

[list store /Users/me/my-videos/20230714_171857.mp4
/Users/me/my-videos/20230714_164304.mp4
/Users/me/my-videos/20230714_154610.mp4
/Users/me/my-videos/20230714_154522.mp4]

...I get the result I want in the patch but I want to use openpanel 2 instead of copy&paste.

Should I convert the output of [openpanel 2] to a message and then loadbang this message into list store upon load or what? I usually save values in patches by setting messages but something is lost in translation... [list store] does not seem to store anything with the patch.

:/

Notice that the delay times are different, feeding into the two outputs. So the two outputs will be different. That means, if you feed one of the channels to the left speaker and the other to the right, you will get some sort of stereo imaging.

BUT your second screenshot shows you flattening the two reverbs' stereo images down to mono.

• sf-play2 L output --> reverb (L and R) --> sum reverb L and R to mono --> left channel
• sf-play2 R output --> reverb (L and R) --> sum reverb L and R to mono --> right channel

I think this will produce a weird stereo image. I wouldn't do it this way. You might try mixing the two reverbs' left outputs together, and the two right outputs together.

But, if you want a more realistic stereo reverb for a stereo input, then I would not use a mono-input reverb. I usually recommend [rev3~] in my course (which is 2-in, 4-out but I just drop the 3rd and 4th outputs).

The reason why is that a mono-input reverb doesn't know where in the stereo field the source is. So you get an illusion of more space, but the stereo imaging will be less precise than a stereo-in reverb.

hjh

@60hz said:

It works for me, but you certainly need to refresh the [number 15( message AFTER create the [pd boid] subpatches creation.

Also, here is a better version using [clone] object that has been part of puredata and makes the design more convienient.

(Note that boids Gem examples need [poltocar] object fom cyclone to work well)

boids2d_clone_Gem_example.zip

Hi, your patch works fine, the boids move correctly, but when I increase their number for example from 15 to 115, also doing the "refresh after..." as you said, the boids increase but stay still, they don't move.
Now, when I open your patch, I get these errors:

--------------------------------------------------------------------
:: Cyclone 0.6-1; Released june 8th 2022
:: License: BSD-3-Clause (aka Revised BSD License)
:: Copyright © 2003-2021 - Krzysztof Czaja, Hans-Christoph Steiner,
:: Fred Jan Kraan, Alexandre Porres, Derek Kwan, Matt Barber
:: and others.
:: -----------------------------------------------------------------
:: Cyclone 0.6-1 needs at least Pd 0.52-0
             (you have 0.52-1, you're good!)
:: Loading the cyclone library did the following:
::   - A) Loaded the non alphanumeric objects, which are:
:: [!-], [!-~], [!/], [!/~], [!=~], [%~], [+=~], [<=~], [<~],
:: [==~], [>=~] and [>~]
::   - B) Added /home/a/Pd/externals/cyclone
:: to Pd's path so the other objects can be loaded too
:: but use [declare -path cyclone] to guarantee search priority
:: in the patch
--------------------------------------------------------------------

opened alsa MIDI client 130 in:1 out:1
declare: Gem: unknown declaration
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
 canvas.top
... couldn't create
boids2d 2005-2006 a.sier / jasch    1995-2003 eric l. singer   Jan  1 2023 13:49:25

These are my startup paths:

** [poltocar]** object appears to be in place:

a@a:~$ cd /home/a/Pd/externals/cyclone
a@a:~/Pd/externals/cyclone$ ls
[CUT]          

poltocar.d_fat           
poltocar~.d_fat          
poltocar-help.pd        
poltocar~-help.pd        
poltocar.l_amd64        
poltocar~.l_amd64        
poltocar.l_arm           
poltocar~.l_arm        
poltocar.l_i386         
poltocar~.l_i386         
poltocar.m_amd64        
poltocar~.m_amd64        
poltocar.m_i386          
poltocar~.m_i386        
           
[CUT]

Something is probably missing or i am doing something wrong.

Bye,
a.

@whale-av said:

@ddw_music Yes.... buffer.
Maybe some DAWs have implemented a tempo message since then?

Tempo must be available, since plug-ins have been doing e.g. tempo-synced delays for at least a decade already.

(In fact, it is available via Camomile: [route tempo position].)

Anyway... I've been considering solutions, and I think I can do this.

1. Set some threshold close to the beat, but before the beat, say x.9 beats.
2. For the first tick past the threshold, get "time to next beat" = roundUp(pos) - pos = int(pos + 0.99999999) - pos.
3. [delay] by this many beats ([delay] and the tick-scheduler will have been fed "tempo x permin" messages all along).
4. Then issue the tick message to the scheduler, in terms of whole beats (where the time-slice duration is always 1.0).

At constant tempo, I'd expect this to be sub-ms accurate.

If the tempo is changing, especially a large, sudden change, then there might be some overlaps or gaps. But [delay] correctly handles mid-delay tempo changes, so I'd expect these to be extremely small, probably undetectable to the ear.

Half a beat at 60 bpm + half a beat at 120 bpm does indeed = 750 ms -- so the delay object is definitively updating tempo in the middle of a wait period.

I'll have to build it out and I don't have time right now, but I don't see an obvious downside.

hjh

delread~ is not a sample delay it is a tapping buffer.

a tapping delay does not delay "the samples", it delays their content.

plus its minimum delay time is the vectorsize.

i think in pd you would replace [delay~ 1] with [fexpr~]... something like x = x1, no idea about the correct synthax.

First off thank you all for your help and suggestions!
I managed to find a solution with a little help from my friends.

So, my main problem turned out to be that I needed to create my socket BEFORE defining my function. Then only after both of these are done I could set up the string to send to Pd (because Python does this sort of weird recursivey thing).

Also as some of you suggested my string was named badly, first I was using a the wrong variable data type ("b") then I tried to make a string using "str" as a name which confuses Python as "str" is the string data type. So for anyone else dealing with this be sure to call your string something like "data" or "lsdfdjkhgs" but not "str"!

Anyway, it works now and I can send data over to [netrecieve]
incidentally @whale-av 's suggestion to use Pd's built in messaging scripts located in the application folder (pdsend & pdreceive) brought up a lot of interesting possibilities that I will be exploring later and for anybody wanting to send messages between Pd and other programs this looks like a cool way to do it.

anyway, I will share the code here in hopes it will help someone else:

import socket
from obspy.clients.seedlink.easyseedlink import create_client

# first get all the socket declaration out of the way
s = socket.socket()
host = 'localhost'
port =  #put (your) open port here, this is also part of Pd's [netreceive] argument
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host, port))

# then we define our callback which happens when we receive data
# out socket is already set up so we can reference it here in the callback
def handle_data(trace):
    # trace is an obspy.trace class so we must convert to string
    # I have to mess around with this "trace" because it is part of the class my client code is using
   data = str(trace)

   # we can then neatly append a ; with a "f-string" to make it work with Pd's FUDI protocol (Pd messages end in ";")
   data = f'{data};'

   # or
   # data = str(trace) + ';'
   # if you like
   
   # and send it over our socket
   s.sendall(data.encode('utf-8'))

#then AFTER all this my code connecting to the server (that returns the data as a string "trace" above, but the entire part for communicating with Pd is up there, and surprisingly simple despite the 'strange loops'!