@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