playing 10 tracks in sync

Reply to playing 10 tracks in sync on Thu, 14 Sep 2023 08:24:44 GMT

KMETE — Thu, 14 Sep 2023 08:24:44 GMT

for a sound installation I have 10 tracks at the same length that should run in loop. each track is output to a difference output in the sound card.
How can I make sure all track will start at the same time when Pi is turned on?

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 ?

Thanks

Reply to playing 10 tracks in sync on Thu, 14 Sep 2023 11:05:42 GMT

alexandros — Thu, 14 Sep 2023 11:05:42 GMT

I don't know the [sfplay2~] object, but I guess you can do it with Pd's native [readsf~]. Just make sure you give a few seconds to all [readsf~] objects to load their tracks, before you start playing. Just read its help patch.

Reply to playing 10 tracks in sync on Thu, 14 Sep 2023 12:17:45 GMT

caska — Thu, 14 Sep 2023 12:17:45 GMT

your plan should work with sfplay 2 if all instances get the same message at the same time, (such as 1 bang to 1 message to 10 sfplay2)
its easy enough to try out, give it a whirl!

I would put a delay between a loadbang that loads the files, and the one that plays them... to give some loading time beforehand.

Reply to playing 10 tracks in sync on Thu, 14 Sep 2023 14:19:32 GMT

ddw_music — Thu, 14 Sep 2023 14:19:32 GMT

@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

Reply to playing 10 tracks in sync on Thu, 14 Sep 2023 15:39:29 GMT

KMETE — Thu, 14 Sep 2023 15:39:29 GMT

Thanks! will use sfplay2~ then! any difference between using send and receive for starting the instances or between connecting wires?

left and right sides are giving the same results?

Reply to playing 10 tracks in sync on Thu, 14 Sep 2023 17:47:56 GMT

oid — Thu, 14 Sep 2023 17:47:56 GMT

@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.

Reply to playing 10 tracks in sync on Thu, 14 Sep 2023 19:57:17 GMT

seb-harmonik.ar — Thu, 14 Sep 2023 19:57:17 GMT

@oid all symbols end up in the hash table, the way send works is by having a linked list of receiver objects in the send name symbol itself iirc.
However when you use [send] it already has a pointer to the symbol (and list) so it doesn't have to look it up in the table.

Reply to playing 10 tracks in sync on Thu, 14 Sep 2023 20:22:22 GMT

oid — Thu, 14 Sep 2023 20:22:22 GMT

@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?

Reply to playing 10 tracks in sync on Thu, 14 Sep 2023 21:40:13 GMT

jameslo — Thu, 14 Sep 2023 21:40:13 GMT

@KMETE You could also make a 10 track wav file and play that back.

Reply to playing 10 tracks in sync on Fri, 15 Sep 2023 01:11:13 GMT

seb-harmonik.ar — Fri, 15 Sep 2023 01:11:13 GMT

@oid basically everything (including 'anything' selectors) that can't be parsed into a float or special symbol (like dollarsign numbers) is converted to a symbol and stored in the table. That includes things in message boxes
afaict that includes comments too currently. I don't think symbols get removed from the hash table either (as symbol instances aren't reference counted or anything)

Reply to playing 10 tracks in sync on Fri, 15 Sep 2023 07:53:23 GMT

KMETE — Fri, 15 Sep 2023 07:53:23 GMT

@jameslo That is sound interesting, but each tracj should be play independently from difference output of the dac

Reply to playing 10 tracks in sync on Fri, 15 Sep 2023 09:48:52 GMT

alexandros — Fri, 15 Sep 2023 09:48:52 GMT

@KMETE have you given this a try? Or are you asking to eliminate the possibility of an unpleasant surprise? Because I think what you need to do is very simple, and it does make me wander what triggers your query. Also, what @jameslo proposes can also work, as a 10-track audio file will be played from 10 different outlets in your sound file player object, so you can easily route them to any [dac~] inlet you want.

Reply to playing 10 tracks in sync on Fri, 15 Sep 2023 10:43:03 GMT

KMETE — Fri, 15 Sep 2023 10:43:03 GMT

@alexandros
I just gave it a try now and it is working just fine using the sf-play2~ object. I'm using [send] and [receive] and see no difference between this and conneting the wires straight to the objects

Reply to playing 10 tracks in sync on Fri, 15 Sep 2023 12:09:21 GMT

alexandros — Fri, 15 Sep 2023 12:09:21 GMT

Of course you see no difference, since the triggering of the [sfplay2~] objects happens at the control rate, so whether wired or wireless, all messages will reach their destinations before the next sample block starts. Just bare in mind that Pd computes all its audio objects in blocks of samples (64 samples per block, by default), and when done, it makes all the control rate calculations (all objects without the tilde (~)), so your starting messages will all go through in between the same two blocks of samples.

Reply to playing 10 tracks in sync on Wed, 27 Sep 2023 19:10:37 GMT

KMETE — Wed, 27 Sep 2023 19:10:37 GMT

Does any one work with this interface and pd /pi combination?

I will get this card only in few days and for the meanwhile I was wondering if:

Does pi / pd will recognize it immediately or do I need to instal drivers?
Will all the 8 output will be available? or do I need to define something in the pd setting?
I'm using this message to setup the interface setting (marked in green):

Thanks!

edit:
If the files I'm playing are exported at 48000/24 bit - do I need to change the sample rate of pd to 48000 instead of the original 44100, right?

Reply to playing 10 tracks in sync on Wed, 27 Sep 2023 20:42:24 GMT

whale-av — Wed, 27 Sep 2023 20:42:24 GMT

@KMETE Yes you will need to change the sample rate or they will play at the wrong speed.
There used to be...... and must? still be a website for soundcard compatibility with the RPI.
If the RPI can connect to the soundcard then the pins (connections) will appear in the Pd media settings.
There are a few very active Raspberry forums on the web...... a good place to search......
David.

Reply to playing 10 tracks in sync on Fri, 29 Sep 2023 04:53:30 GMT

ddw_music — Fri, 29 Sep 2023 04:53:30 GMT

@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

Reply to playing 10 tracks in sync on Sat, 30 Sep 2023 08:56:33 GMT

KMETE — Sat, 30 Sep 2023 08:56:33 GMT

I was wandering if it makes any difference if the audio files will be play from external usb stick rather then from the pi itself ?

the thing behind the thought to use external usb stick is that it will be much easier to change the audio file when needed - just upload and replace new audio files with the same name. so no need to connect the pi to a screen/mouse/keyboard and replace files rather just put new ones on usb stick.

so is that can effect the performance of the patch? (slower reading from stick?)

thanks

edit: the above is not option because when I first power the pi it won't recognize the usb stick fast enough so the pd patch is not "finding" the files. only if I manually restart the patch it is working

Reply to playing 10 tracks in sync on Sat, 30 Sep 2023 14:15:21 GMT

whale-av — Sat, 30 Sep 2023 14:15:21 GMT

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

Reply to playing 10 tracks in sync on Sun, 01 Oct 2023 03:18:09 GMT

ddw_music — Sun, 01 Oct 2023 03:18:09 GMT

@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