As in the title, while listed in the documentation, the library does not export the function.
"sv_set_pattern_event" must be used instead, which can be slow if I have to iterate over large chunks of data.
SunVox Library - sv_set_pattern_data is not exported, or does not exist [not a bug]
SunVox Library - sv_set_pattern_data is not exported, or does not exist [not a bug]
Last edited by Sotakebk on Fri Feb 03, 2023 1:04 am, edited 1 time in total.
- NightRadio
- Site Admin
- Posts: 3955
- Joined: Fri Jan 23, 2004 12:28 am
- Location: Ekaterinburg. Russia
- Contact:
Re: SunVox Library - sv_set_pattern_data is not exported, or does not exist
set_pattern_data() is only for Java (as mentioned in documentation).
In other systems you can use get_pattern_data() for both reading and writing, because it returns a pointer to RW block of memory.
But as far as I understand, in the context of C# there may be problems with this pointer. Or not?
In other systems you can use get_pattern_data() for both reading and writing, because it returns a pointer to RW block of memory.
But as far as I understand, in the context of C# there may be problems with this pointer. Or not?
Re: SunVox Library - sv_set_pattern_data is not exported, or does not exist
Wow, do I feel silly now.because it returns a pointer to RW block of memory
Not at all, it somehow just slipped my mind that it could be asynchronously read/writable like that. I guess I'll get it done that way.But as far as I understand, in the context of C# there may be problems with this pointer. Or not?
Can't it be a footgun, though? Any unexpected behaviour that could happen when not doing it in a lock() unlock() block?
- NightRadio
- Site Admin
- Posts: 3955
- Joined: Fri Jan 23, 2004 12:28 am
- Location: Ekaterinburg. Russia
- Contact:
Re: SunVox Library - sv_set_pattern_data is not exported, or does not exist
You must call get_pattern_data() every time something changes the size of the pattern. There shouldn't be any other pitfalls, especially if everything is done in one thread.Can't it be a footgun, though? Any unexpected behaviour that could happen when not doing it in a lock() unlock() block?
In multithreaded code, a rare conflict can occur when reading and writing the same line of the pattern at the same time. As a result, for example, a note may hang. To avoid this, wrap the pattern change code with lock()/unlock()