dapinsker

I've created a random file player that utilizes sfplay`preload cues. The files I'm culling from are stored in subfolders of the main patch, simulating the hierarchy found in most video games. This patch works without any issues on my PC. However, it does not work on my Mac.

I know that this can be done using umenus as well as drop folders. In addition, I know that I can simply save the files directly in the main folder that the patcher lives in. However, I am using this patch to teach my students the importance of file management and saving files in subfolders.

Anyone have any ideas why the Mac doesn't like this patch but the PC does? It is a MacBook Pro running Leopard. Any ideas that might resolve the situation?

I've created a random file player that utilizes sfplay`preload cues.  The files I'm culling from are stored in subfolders of the main patch, simulating the hierarchy found in most video games.  This patch works without any issues on my PC.  However, it does not work on my Mac.

I know that this can be done using umenus as well as drop folders. In addition, I know that I can simply save the files directly in the main folder that the patcher lives in.  However, I am using this patch to teach my students the importance of file management and saving files in subfolders.

Anyone have any ideas why the Mac doesn't like this patch but the PC does?  It is a MacBook Pro running Leopard.  Any ideas that might resolve the situation?

sfplay-mac-vs-pc-issue

Paths are relative to the directory from which the Max application is run, usually 

 on OS X. It should works that way on Windows too, though there may be different behaviours.

 or scripting to obtain patch-relative paths.

Here is a standard solution. Note that as it depends on 

 you have copy-paste it into your top-level patch (and reopen it to activate the 

). You may encapsulate all objects except the 

Paths are relative to the directory from which the Max application is run, usually /Applications/Max5 on OS X. It should works that way on Windows too, though there may be different behaviours.

You have to use thispatcher or scripting to obtain patch-relative paths.

Here is a standard solution. Note that as it depends on thispatcher you have copy-paste it into your top-level patch (and reopen it to activate the loadmess). You may encapsulate all objects except the thispatcher into a subpatch though.

Thanks for your post Hans. I was trying very hard to avoid scripting. I've experimented with patches similar to the one you posted. The thispatcher solution is a good one. I've toyed with this in the past. It does work, but takes a bit of explaining for a student with extremely limited Max experience.

I am far more perplexed as to why the original patch works on a PC, but not on the Mac. I understand about the folders being relative to the Max application itself. I also know that I can change the Max's search preferences to search user defined locations. However according to Max's documentation, the file search should also include the patch that is currently being loaded. With that said, the ./folder argument that I have placed in the message boxes should cause Max to search in the subfolders of the main patch being loaded. I'd be interested in knowing why this isn't happening.

Thanks for your post Hans.  I was trying very hard to avoid scripting.  I've experimented with patches similar to the one you posted.  The thispatcher solution is a good one.  I've toyed with this in the past.  It does work, but takes a bit of explaining for a student with extremely limited Max experience.  

I am far more perplexed as to why the original patch works on a PC, but not on the Mac.  I understand about the folders being relative to the Max application itself.  I also know that I can change the Max's search preferences to search user defined locations.  However according to Max's documentation, the file search should also include the patch that is currently being loaded.  With that said, the ./folder argument that I have placed in the message boxes should cause Max to search in the subfolders of the main patch being loaded.  I'd be interested in knowing why this isn't happening.  

Max does not perform recursive (i.e. subdirectory sensitive) search when an object is created. This is good, because recursive search may be very time-consuming. However, when you add paths in the File Preferences dialogue, there is the possibility of having every child path of the selected path included as well, by checking the Subfolders box. This means that the short list in File Preferences usually translates to a much longer which is the 

When a patcher is loaded, Max automatically adds the directory of the file from which it is loaded (which we can obtain by 

 as above), to the seach path. However, it makes no attempt to combine directories already therein with the directory of the loading patcher.

 is a standard sign used in shells, which expands to the current directory (or cd). The cd is, by definition is the directory from which the currently executing program was invoked, i.e. directory that contains the Max application. Probably your Windows system have some different notion of cd than OS X which follow UNIX standards.

Max does not perform recursive (i.e. subdirectory sensitive) search when an object is created. This is good, because recursive search may be very time-consuming. However, when you add paths in the File Preferences dialogue, there is the possibility of having every child path of the selected path included as well, by checking the Subfolders box. This means that the short list in File Preferences usually translates to a much longer which is the search path.

When a patcher is loaded, Max automatically adds the directory of the file from which it is loaded (which we can obtain by thispatcher as above), to the seach path. However, it makes no attempt to combine directories already therein with the directory of the loading patcher.

The . is a standard sign used in shells, which expands to the current directory (or cd). The cd is, by definition is the directory from which the currently executing program was invoked, i.e. directory that contains the Max application. Probably your Windows system have some different notion of cd than OS X which follow UNIX standards.

This makes perfect sense. It definitely explains the discrepancy between the functionality of the two operating systems.

This makes perfect sense.  It definitely explains the discrepancy between the functionality of the two operating systems.


sfplay~ Mac vs. PC issue