Do you plan to provide playback code for developers to integrate their compositions into their games?
If so how much CPU is required for playback? Maybe it's too early to say?
Do you plan to provide playback code for developers to integrate their compositions into their games?
If so how much CPU is required for playback? Maybe it's too early to say?
I've been continuing this project purely for "track-making" on Playdate, so I hadn't anticipated game developers incorporating the compositions made by Yacht for their games. However, I am interested in making that happen!
Playback essentially utilizes the playdate.sound API. Synthesis and Sample player too. The composed song data is exported (saved) as JSON, but it's not compatible with formats used in libraries like Pulp. Nevertheless, should be able to implement that playback engine it relatively easily.
In the early stages of the project, I created a "musical tick" using playdate.resetElapsedTime(), but it was unstable. So, I'm using the classic method of tempo management by watching dummy playdate.sound.sequence. However, playdate.sound still has its quirks, and I've noticed occasional tempo glitches, which is why I set the FPS to "0". This might not be ideal for most game developers!
do you have any ideas?
for reference song data in Lua
song = {
name = "song1",
bpm = 120.0,
volume = 1.0,
length = 32, -- song bars
tracks = 4, -- tracks synth1,2,3+drums(4ch)
struct = {
-- song struct
{ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 },
{ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 },
{ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 },
{ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 },
},
synth1 = { -- synth track
waveform = 1,
volume = 1.0,
pan = 0.0,
attack = 0,
decay = 0.1,
sustain = 0,
release = 0.0,
pattern = {
{
length = 16,
direction = 1,
notes = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }
-- note numbers, 0: noteoff, 128: legato
},
-- ......
},
},
drum1 = { -- drums track....
bank = 1,
type = 4,
volume = 1,
pan = 1.0,
pattern = {
{
length = 16,
direction = 1,
notes = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }
-- boolean
},
-- ......
},
},
}
Synth and sample should be light enough. Frame rate or timing issue will take some consideration.
this app is going to be really, really good. I added some notes on the itch.io page about some possible control improvements. Nice work!
Thank you for your very meaningful comments!
your opinion is valid.
I think I'll try working on these!
I was worried about changing the name because I really liked it, but
We will consider changing this in the next major update.
Where can I try your app?
I've created an NES-like GUI, but maybe I need to implement a Macintosh/GameBoy-like experience.
Tabs and scrolls are the most appropriate approach.
This requires more pixels!
Currently the screen scale is set to x2, this is done to increase fps. . . . But now I know that doesn't make much sense, so maybe I need to make it more user friendly.
I'm thinking of a way to combine Lua and C.
I have made an NES-spec LSFR/Wavetable synth using Arduino C++.
Someone said on the forum, "If you want to implement Wavetable with Pd, use C," but I don't really understand what that means...
I think @dave might have some ideas. I recall he said he had recently been looking into something related?
probably...
I think classic game creators or "sound developers" like us prefer to implement algorithms per sample rate rather than sampling (e.g. SoundFont).
Currently, the Lua API only allows access to static wavetables.
But in C, "playdate->sound->synth->setGenerator" exists.
I would like to combine my current code with this. but so hard to meðŸ˜
This one is more recent and is what I was referring to
This was his comment on my post!
Vector synthesis really excites me.
However, my current APP is just following their API, so I would like to add original synthesis.
If Music created with Yacht is ported to other games, this suggests the possibility that SFX can also be ported.
next version plan (v0.2)
some new ideas
Those ideas look awesome!! Especially love the mixer
Version 0.2
I think the previous version was 1.0 , but this time it's "0.2".
The synthesizer functions and UI have been renewed.
It's still unstable, but "barely" working.
New
Known issues
Next
Note
To give up scene switching with the crank and go to the SWITCH screen, use the "B" button. However, this is still incomplete. Thanks @deanhuff.
and do you have any ideas?
Maybe there are some lessons to learn from the SDK music playback code that can be exported from Pulp?
I'm using it in my game YOYOZO to play back "chip tune" music and the tempo is 99% solid. In fact I decided to control it dynamically as the player improves. My game runs at 40fps, base music tempo is 135bpm.
I took a look at the data of the pulp, and it appeared to be in a MIDI-like format.
In this app, it is formatted MOD-like. It is built on the idea of creating loops (PATTERNS) and connecting them.
(I believe I will eventually need to implement a function to convert it to the pulp format.)
Now, in this app playing the note data that is being saved in an array by watching the ticks of the sequencer,and using instrument:playNote(), without using the API sequencer.
It was much easier to read and write data directly to the table than to interact with playdate.sound.track.
Is your playback method compliant with the API?
If it is, then I will consider it...
Sorry, I wasn't clear enough with my previous suggestion. Pulp can export song data and also a playback engine in SDK Lua. I use both.
Maybe the playback engine can suggest some tricks for you to keep stable tempo.
Thanks! I didn't know about that. . .
I read "pulp-audio.lua." It seems they are generating "ticks" with playdate.sound.getCurrentTime()
.
This was an idea I hadn't thought of. If it is hooked on audio frequency, it might have a cycle of 44.1kHz. Since this isn't the so-called musical grid, a function might be needed to convert this. As playdate.sound.getCurrentTime()
should be defined as a more accurate clock within Pd, this could be a way to solve the issue.
However, I also believe that the "watch-from-playdate.sound.sequence" method that I made is also built upon that clock, so this area should be investigated, I think.
How's it going with this?
Uh, I've been busy with other projects and haven't touched the code at all.
I actually thought about playing with this and improving it, but I never had the situation to use this myself to create music on this year.