@whale-av said:

But there is still a limit...... 198 is it...... in 32-bit extended

How? ...

Vanilla 0.53 will not show a result for either with input > 34...... a big for extended.and for vanilla.

The largest possible exponent in 32-bit float is 38. With an input of 34, you're already reaching this limit. Anything above that will be an incorrect result, so I'd say to extended for providing a false answer and no indication that the result is false. (Unless you meant 64-bit extended... but the exponent limit in 64-bit floats is 308, and 198! = 1.9815524305E370, also outside the limit... so even in 64 bits, 198! is a garbage result.)

hjh

@whale-av said:

@KMETE Try delaying the loading of the files in the patch....... [loadbang] [delay 5000 or some suitable value ]
David.

Just to show how that's done with my [stereofile] abstraction (already noted in the thread that this is being used in kmete's patch):

BTW for this approach: I just fixed a bug where it would try to load even if no path was given. Not a catastrophic issue but it would print a spurious error. So you should update from https://github.com/jamshark70/hjh-abs -- now [stereofile] will await instructions instead of prematurely complaining.

hjh

@whale-av said:

@KMETE Yes you will need to change the sample rate or they will play at the wrong speed.

[sf-play~] and [sf-play2~] automatically scale playback rate so that rate 1.0 is the file's normal sounding rate... as in it's a properly functioning sample player wherein the user isn't responsible for internal implementation details

hjh

@bamsehopp said:

Thanks a ton for that patch, It works great!

Oh, glad to hear that, I did only the barest minimal testing so I wasn't sure if there were any bugs. I had done state machines in SuperCollider but not so much in Pd up to this point.

hjh

"Easy," not really -- because the meaning of byte 'n' depends on what was byte 'n-1'. The current received byte has to set the routing for the next byte, which is a bit outside of normal straight-shot patching.

However I tested this with some simulated messages (including running status bytes) and it does seem to parse them out correctly. You could extend it for other message types too, but I don't have time to go further than this.

23-0916-midiin-state-machine.pd

hjh

@KMETE said:

If I give the message [1) to all the sfplay2~ objects they should all start at the same time? or it might have some delays ?

No delays. sf-play2~ is reading from memory, so each one will start instantaneously.

hjh

@esaruoho said:

wow, even having one ceammc ui.menu displaying results in the else/multi.vsl's grinding to a halt updating-wise, no more being able to draw content onto them. looks like i'll not be able to use them then

What is your update rate? And are you updating using "import" or by sending one index-value pair per slider?

hjh

Side question: Are the ceammc externals available as a separate package for Linux? (They aren't in deken.) Or the only way is to build the entire ceammc pd package?

hjh

@jameslo said:

I'd still like to know if spaces are legal and possible with [oscformat] though.

I'm a bit surprised to see this, but in fact, according to the OSC spec 1.0, spaces are not allowed in OSC command paths.

https://ccrma.stanford.edu/groups/osc/spec-1_0.html#osc-address-spaces-and-osc-addresses

Each OSC Method and each OSC Container other than the root of the tree has a symbolic name, an ASCII string consiting of printable characters other than the following:

-character-	-name-	-ASCII code (decimal)-
’ ’	space	32
#	number sign	35
*	asterisk	42
,	comma	44
/	forward slash	47
?	question mark	63
[	open bracket	91
]	close bracket	93
{	open curly brace	123
}	close curly brace	125

So Pd has no obligation to support spaces here.

I suppose it depends on the software's OSC handler. SuperCollider doesn't complain (contrary to the OSC spec):

n = NetAddr.localAddr;  // send to myself

o = OSCFunc({ |msg|
    msg.postln;
    o.free;
}, '/test space');

n.sendMsg('/test space', 1);

prints: [ /test space, 1 ]

I did some other tests:

• "symbol patch 1" --> [list fromsymbol]: escape char 92 is not in the ASCII list.
• list "112 97 116 99 104 32 49" --> [list tosymbol]: resulting symbol prints with a backslash. I don't know if the backslash is stored internally, or if it's inserted only for the printed output. A quick look at the source code in x_list.c suggests that the backslash is not stored internally.
• list "112 97 116 99 104 32 49" --> [list tosymbol] --> [list prepend set] --> [list trim] --> [oscformat]: The printed bytes from oscformat do include char 92. But I couldn't see in the source code where the space is being escaped. (This long way around to build the "set" message is to be certain that there's no backslash in my input -- the backslash must be generated internally somewhere..)

So [oscformat] seems to be where the problem is happening -- but the OSC spec makes no promises that spaces will work, so there wouldn't be any justification to log a bug.

hjh

If you pad the source array with 1 preceding point and 2 trailing points, tabread4~ can do it for free (not linearly, but it's nice).

Read the tabread4~ helpfile about those leading and trailing points.

hjh

@esaruoho said:

if it helps, i'm trying to simulate tuning forks, or an acoustic instrument, well, not simulate, but the "release/decay" portion of it. i.e., "die after 5 seconds" or "die after 15 seconds".

Sounds like a job for a decaying filter. I did this a while back.

0606-decay.pd

Edit: The patch says the energy doesn't have to be an impulse, but if it's longer than an impulse, energy will accumulate above 1.0 and then take longer to reach silence. So for enveloping purposes, the one-sample impulse makes the most sense as a trigger.

Edit 2: If you take two of these rpoles, one with a longer decay time and the other with a shorter time, and subtract longer - shorter, then you get a nice smooth attack-decay envelope (Decay2 in SuperCollider).

hjh

@seb-harmonik.ar said:

I'm guessing supercollider does something similar, so when it creates all of those strings it actually has to allocate each of them on the heap separately rather than allocating the array with the space for each already included.

It's a good point, however in SC this is true of the Symbol class. My benchmark is using Strings, which are arrays of characters and not retained in a hash table. (But the hashing overhead might explain why SC built the collections faster.)

(plus it would have to know the max size of a string to do that too which would also waste memory in a lot of cases where the data stored was smaller than that)

For SC Symbols, I'm not sure. For String.fill, the size is given and it can allocate exactly that amount.

hjh

@ddw_music said:

By contrast, if, in SuperCollider, I made 4 arrays of strings with 10 items, 100, 1000 and 10000 respectively, I'd expect it to go at least an order of magnitude faster, maybe two orders, because array indexing in SC is O(1) (so the entire fill would be O(n) provided that you allocate all the array slots in advance -- since the number is known, that's easy).

That turned out to be wrong:

(
var letterA = $a.ascii;

f = { |n| Array.fill(n, { String.fill(50, { (26.rand + letterA).asAscii }) }) };

bench {
    a = [f.(10), f.(100), f.(1000), f.(10000)];
};
)

time to run: 0.06757064 seconds. ~= 0.07

About half. So a lot of the time is spent just generating the strings, I guess, in both environments.

Repeating the array-read benchmark in SC, though... this is what O(1) array lookup looks like:

(
a.do { |array|
    var n = array.size;
    (n.asString ++ " elements: ").post;
    bench {
        1000000.do { array[n.rand] }
    }
}
)

   10 elements: time to run: 0.038383661000012 seconds.
  100 elements: time to run: 0.035132123000039 seconds.
 1000 elements: time to run: 0.033579056999997 seconds.
10000 elements: time to run: 0.034433505999914 seconds.

... no performance degradation for higher sizes.

hjh

Also... That 120 ms to populate 11,110 rows seems like a lot. Every "text set" does nthline again... so one row's insertion is O(n), and filling a text with n rows would be O(n^2), which is one of those computer science performance red flags. (If you need high performance, avoid O(n^2) algorithms!)

By contrast, if, in SuperCollider, I made 4 arrays of strings with 10 items, 100, 1000 and 10000 respectively, I'd expect it to go at least an order of magnitude faster, maybe two orders, because array indexing in SC is O(1) (so the entire fill would be O(n) provided that you allocate all the array slots in advance -- since the number is known, that's easy).

[text] just isn't written for maximum performance. Query speed seems acceptable but with a better optimized data structure, it could be even faster. It's why, when I made a scheduler for pd, I had the heap operate on numbers only in an array (fast) and access the text only when needed.

hjh

@zigmhount said:

TL;DR: Is it more efficient to [text search], [text get] and [text set] 91 times in one [text] object, or to [text get] and [text set] 1 time in each of 91 [text] objects? or in 91 [list] objects?

Going back to the original question...

In the source code, the function that locates a line by number is text_nthline(). This implements a linear search from the beginning of the text buffer, counting character by character, until it's crossed n newlines (semicolons or commas).

So performance will depend on how many lines, and how long the lines are.

Accessing lines near the end will be slower than accessing lines near the beginning.

For a linear search, you would predict that the time is proportional to the size. I built a benchmark where the lines are all roughly the same size, comparing 10 lines vs 100, 1000 and 10000, doing a million random accesses for each one.

23-0826-text-performance.pd

The smaller buffers are a bit slower than "linear" would predict, but this is probably because of function call overhead and can't be avoided. (x1000 vs x10000 is linear.)

Still, if you're wondering how a single text buffer of ~100 lines would do... 100 ms for 1,000,000 queries is pretty fast. So... don't worry about it...?

Or you could run this yourself on the lower-end laptop that you mentioned. (But... before you do... go into the [pd 1000000_queries] subpatch and change the 1e+06 message box to, say, 10000 or 100000. Otherwise you might be sitting there a while. And be sure to init the buffers first, should be clear where to click.)

I didn't benchmark the performance of accessing multiple separate text objects. Based on the source code, if you access line 0, then text_nthlne() will scan only the one line (to determine the endpoint). I don't know what is the overhead of switching a [text get] between buffers.

Honestly I think the Pd GUI stuff will be a heavier drain on CPU than either [text] approach.

hjh

Dorisma said:

I don't use the audio wav files format anymore because it is difficult to read and causes many problems. Instead, I decided to convert on https://convertr.org/wav-to-mp3 all the files in mp3 format supported by any application.

I realize this is a couple years old comment now, but: [soundfiler] does not support mp3 format.

I'm not sure which audio programming environments do support MP3.

• Pd, no ("soundfiler read: /home/xxxxx/Music/23-0714-ambient-jam.mp3: unknown header format").
• Max/MSP, no ("can't open").
• SuperCollider, no ("File '/home/xxxxx/Music/23-0714-ambient-jam.mp3' could not be opened: Format not recognised.").
• I don't have ChucK or Reaktor, can't test those. Reaktor might support MP3 since it's a commercial product. ChucK... reference docs for SndBuf seem difficult to locate, so, I give up, I don't know.

So the approach of converting all WAVs to MP3 seems to be based on a mistaken assumption. For use with Pd, this is not the way to go.

hjh

@cfry said:

I understand that for this type of operation should use the text object (maybe it even accepts file names with blank spaces?). However text seems to require semi-colons as separators for a list.

When you add entries into [text] line by line, [text] adds the semicolons for you.

I guess that open panel 2 returns a list with return as separators?

Don't guess -- examine the data!

But one key here is that a list in Pd is not "space delimited." When you print a list to the console, or put a list into [text], then the text representation of the list uses spaces in between list entries but the spaces don't exist internally. So when you say "maybe it even accepts file names with blank spaces" -- a symbol may contain a blank space, yes, this is not a problem. When Pd writes a symbol out to print or [text], the textual version tells the difference between a space within a symbol and a space between entries in a list by putting a backslash before the space inside the symbol.

If you see the quick brown fox in a text box, it's a list with 4 symbols.

If you see the\ quick\ brown\ fox in a text box, it's one symbol containing the whole phrase.

Openpanel should give you one symbol per filename, including special characters, encoded as normal strings. When you put it into a text object, it should encode for storage (escaping special characters), and when you retrieve from the text object, it should decode so you get the original strings out.

This is why I asked which special characters you're having trouble with. It's supposed to be handled for you.

How could I set this up with text object?

Easiest way is: If you get a list from openpanel, just dump the list into one line of [text]. The text window itself would just have one big long line but it "should" work.

For a more readable text window, list-drip and push the symbols in one by one.

hjh

@fishcrystals said:

its not always so easy to deal with newlines and other special characters like slashes

Not sure what you mean here. AFAIK a forward-slash is not a special character in Pd. Since this thread is about saving paths, and paths in Pd use forward slashes (even in Windows), it should be fine...?

If the symbol contains special characters (e.g. as a result of [openpanel]), then it will be written into the [text] encoded with special characters. That is, I just tried to put a symbol containing a semicolon into a [text], and the text's contents show a\;b; where \; represents the semicolon within the symbol, and the final ; is the end of line delimiter. So that much is handled automatically.

Unless you meant that special characters are tricky to handle when setting message box contents? ... which is true, but "/" is not a special character there either.

@seb-harmonik.ar:

the only way to store things within a patch is in message boxes or with [savestate]

[text define -k xyz] will save in-patch.

hjh

@esaruoho said:

hi, i'm not sure what Ping in TouchOSC is?

If it's enabled, then TouchOSC running on the tablet will send a /ping message to the outgoing address/port at the moment when you activate the TouchOSC interface and every 30 seconds after that. This is an easy way to get the tablet to send a message to the computer right away, so that the computer can get the IP and port that the tablet is sending from.

hjh

@dreamer said:

So they still use Macs, but pirate all the software for it? Kind of odd.

The rich kids use Mac. Most use Windows. And Linux...? While it barely exists for consumers in the West (I'm a 13+ year Linux user btw, and I have no plans to switch to a commercial OS, but I'm honest about Linux's market share), it doesn't exist at all over here.

There seems to be an assumption that commercial software is always better than free... which is often true... so it's "why would I deal with a smaller feature set and less elegant UI in, say, GIMP when cracked PhotoShop is a few clicks away?" (I do use GIMP myself.) There are exceptions, though (e.g. AFAIK there's nothing like SuperCollider in the commercial sphere). So I like these edge cases where FLOSS ends up being more broadly usable.

hjh