@whale-av said:

@esaruoho I have found the very small investment in TouchOSC

Great app!

TouchOSC and Open Stage Control are similar but different.

Open Stage Control is a server and thin client. The server runs in Windows, Mac or Linux. It ships with its own client for editing, but you can also point Firefox or Chrome to it, with full access to editing features in the browser as well. The server can load any number of "sessions." One session is synced across any number of clients. If I open the same session in multiple browsers, moving a control in one window will update all of them at once.

So it's client window --> server --> OSC messages to an address of your choosing.

One nice feature is that starting the server prints a QR code in the console, which you can scan in mobile Firefox to open the page, without typing an IP address. Typing the address always annoyed the **** out of me.

At this point, I feel like this works out better for me than TouchOSC. But, Open Stage Control doesn't send accelerometer data. I never used it extensively, but it was nice to have.

Open Stage Control is also free and open source, no proprietary app you have to install on your device.

Here's Open Stage Control driving SuperCollider:

hjh

Have a look at Open Stage Control. It's not all Pd native but it will let you create sliders on the tablet and receive the values in Pd.

hjh

@Obineg said:

90% of the humans are not even able to give answers which sound correct.

I'm not sure which is worse: an idiot who is obviously wrong, or an idiot who sounds thoroughly convincing.

I don't have the link handy, but one commentator called GPT a "mansplaining machine" -- often wrong, but projecting absolute confidence in its answers.

Social media haven't helped, because every damn moron's opinion gets preserved in the digital record instead of being forgotten by the time you get home from the pub. So we get used to stupidity acquiring the air of legitimacy that comes simply from appearing in print.

@Obineg said:

chatGPT is more intelligent than 90% of the world population

It's not. It makes up answers that sound correct, but not based on real understanding. This may change at some point but it's not there yet.

If humans can't tell the difference, that's humans' fault.

hjh

@KMETE said:

I was wondering if there is any difference between multiple sf-play2~ or readsf~ in term of memory usage?

[stereofile] loads the contents into RAM. (sf-play2~ is only the player, not the loader, but it depends on audio data loaded into RAM by stereofile.)

readsf~ streams from disk so its RAM usage should be much smaller.

One of the reasons why I worked on stereofile and sf-play2~ is that I think if you tell it to play an audio file at rate = 1, then it should sound like the file's normal speed at any Pd sample rate. Pd's built-in [tabplay~] does not do this -- if the system sample rate differs from the file's rate, it will play faster or slower than normal. That is, system settings affect the patch's behavior . I think [readsf~] also has this problem but I haven't checked, could be wrong about that.

hjh

@KMETE said:

what is the best method of playing multiple files without the need to multiple everything?

sf-play2~ accepts a symbol in the right-hand inlet, to change the buffer being played. (That is, this -- "With [sf-play2~] I think you will have to use multiple players as you did here" -- is incorrect. I'd be a terrible programmer if I made the abstraction so inflexible.)

hjh

I think this handles the left-hand overlap problem.

I did not insert a note-off for rearticulated notes, so this patch is incomplete. Also the right-hand time-window idea is not implemented here... but it's all the time I have right now.

23-0521-midi-split.pd

Like a lot of software problems, it seems like a lot of the difficulty is in defining the requirements.

jameslo is 2000% correct about this. Often the working method is "let me throw some objects into the window and hope some of it sticks." The usual result of that is confusion.

hjh

@Alan-Angel said:

1. I don't plan on play two left hand notes, I just want to play fast galloping basslines like dun du-du dun du-du dun du-du dun and it'seasier to do with one hand and play the notes with the other, like a real bass.

OK, so, hold a pitch with the right hand and play fast notes with the left -- rhythm and articulation under control of the left hand. So that removes some cases.

However... user-interaction data are always dirty. You say "I don't plan on..." but in practice, when you're playing, the actual MIDI messages coming in will not always conform to the ideal. So if your patch is like "it works as long as I never X"... trust me... sometimes X will happen... the patch needs to be able to handle it.

E.g.:

I think the following two scenarios are guaranteed to happen sometimes:

1. You hit the right and left hand notes "at the same time" but the left-hand note arrives first. If the logic here is "nothing is currently held in the right hand, so, do nothing," then the first note will become a rest. So there should probably be some logic such as "if the right-hand note arrives within a certain time window after the left-hand note (like 20-30 ms or less), then play it once both are received."

2. While rolling the fingers over G-A-B in the example, some of them overlap. If you're using left-hand note-off to release notes, and you don't account for overlaps, then some notes will be cut off prematurely.

For problem 2, assuming mono, you would release a playing note if the note-off matches the last note to be played:

1. note on 43
2. note on 45 -- then, quickly, note-off 43
3. note on 47 -- then, quickly, note-off 45
4. note off 47

At 2, note-off 43 should not cut the note off because it isn't the currently active trigger note number (but, since note-on 45 is rearticulating, then it will have to generate a note-off before the next repeating note-on!). But, at 4, note-off 47 should cut off the note.

I'm not sure I have time myself to build all of this, but maybe I can do some pieces of it and post them later.

hjh

My question about this:

• Right hand first, then left hand: Note should be produced upon the left-hand note on.

  • What if one right-hand note is pressed, and two or three left-hand keys? Multiple notes, or only the first? (Polyphony, I suppose, would have to be right-left, right-left, not the same as right-left-left.)

• Left hand first, then right hand: Should it play the note upon receipt of the right hand note-on, with the left-hand velocity? Or not play anything? Or something else?

  • And, if it should sound, what about left-right-right? Portamento? Ignore the second?

Because a full solution will be different depending on the answer to these questions. These need to be thought through anyway because you can't guarantee correct input -- the logic needs to handle sequences that are not ideal, too.

hjh

Instead of the message box, use [pack f 500] (could be [pack f f] but the 500 initializes the time value).

The [pack] will have two inlets. Your random result goes into the left inlet; the time goes into the right inlet.

Then you can dump the "$1 500“ message box.

hjh