This module aims to simplify the process of adding multiple music tracks to Foundry VTT, allowing for bulk importation of songs.
If you're like me, you probably enjoy amassing a large collection of songs to play for your players! However, importing your songs one at a time can be sluggish and time consuming. Playlist importer allows you to bulk import all of your songs!
I will only personally be maintaining the most recent version of foundry. In short, this means you may not get backwards compatibility for any breaking changes. Fortunately, you should be able to use releases to download a compatible version if it exists.
It's always easiest to install modules from the in game add-on browser.
To install this module manually:
https://raw.githubusercontent.com/JacobMcAuley/playlist_import/master/module.json
Please read the following, as it may answer any questions as to unexpected behavior.
NOTE:
Note: The paths are vague, as you may have a different data path for your instance of FoundryVTT. If you have questions, feel free to message me.
| /FoundryVTT/Data
|
|---> /music <----- This should be selected as the directory
| |
| |------> /battle_songs
| | |
| | |----> cool_battle.mp3
| | |
| |------> /epic_songs
| | |
| | |----> epic_battle.mp3
| | |----> last_stand.mp4
| |------> /tavern_songs
| | |
| | |----> gnarly_gnomes.mp3
| | |
| |------> /peaceful_songs
| | |
| | |----> safety.mp3
| | |----> just_kidding.mp4
npm install
will build the code and copy all necessary assets into the dist folder and make a symlink to install the result into your foundry data; create a
foundryconfig.json
file with your Foundry Data path.
{
"dataPath": "~/.local/share/FoundryVTT/"
}
build
will build and set up a symlink between dist
and your dataPath
.
npm run-script build
You don't need to build the foundryconfig.json
file you can just copy the content of the dist
folder on the module folder under modules
of Foundry
build:watch
will build and watch for changes, rebuilding automatically.
npm run-script build:watch
clean
will remove all contents in the dist folder (but keeps the link from build:install).
npm run-script clean
lint
launch the eslint process based on the configuration here
npm run-script lint
lintfix
launch the eslint process with the fix argument
npm run-script lintfix
prettier-format
launch the prettier plugin based on the configuration here
npm run-script prettier-format
package
generates a zip file containing the contents of the dist folder generated previously with the build
command. Useful for those who want to manually load the module or want to create their own release
npm run-script package
Thanks to Ariphaos for their help with creating a more user friendly naming convention when importing playlists!
Thanks to Sciguymjm for all the suggestions for improvements to the importer! Thanks to users JJBocanegra, Jlanatta, and JMMarchant, and mikkerlo for assisting in the development of Playlist Importer.
Spanish: Thanks to Lozalojo for providing the Spanish translation.
Songs are added to a generalized hashtable that is checked each time a song is asked to be added. In this implementation, I use the name of the song as the key in which to add to the hashtable. This is the primary reason that unique song names should be used. When attempting to add a song, the hashtable is checked to see if an entry has already been added. Given the notion of hashtables, this should be constant time and at worse O(n) time (if identical song names are used) as it degrades to a list.
This leaves us with the remainder of the operations. Generally hand waiving the API call to add to the playlist as constant time, since it should be adding to the database of songs, we can assume that remaining operations are roughly O(N).
As such here is the plotted time complexity graph for up to 525 songs added at a time. You can see an .html file generated by plotly in images, if you're interested.
Note, because we've assumed that checking if a file exists is constant time, the running time is still approx O(N) as the operation to add scales off the number of files.
Additionally, you times should be faster! To test this, file operations were run on an old HDD approx ~6 years old. This likely means that you should experience better times.
If you notice any errors or have any suggestions, please let me know on discord! (JacobMcAuley#3461)